Content management systems and methods

ABSTRACT

This disclosure relates to, among other things, systems and methods for managing electronic content. Certain embodiments disclosed herein provide for a trusted data management platform that may interact with a trusted assertion service and/or a digital rights management service to manage access to and/or use of electronic content. Content creators and/or other content rights holder may register their content and/or associate rights using the trusted data management platform and/or a trusted assertion service and be assured that their content rights are securely managed and respected.

RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.17/200,251, filed Mar. 12, 2021, and entitled “Content ManagementSystems and Methods,” which is continuation-in-part of U.S. patentapplication Ser. No. 17/067,394, filed on Oct. 9, 2020, and entitled“Trusted Data Management Systems and Methods,” which claims the benefitof priority under 35 U.S.C. § 119(e) to U.S. Provisional PatentApplication No. 62/913,016, filed Oct. 9, 2019, and entitled “TrustedData Management Systems and Methods,” and to U.S. Provisional PatentApplication No. 63/089,517, filed Oct. 8, 2020, and entitled “ContentManagement Systems and Methods.” Parent application U.S. patentapplication Ser. No. 17/200,251 further claims benefit of priority under35 U.S.C. § 119(e) to U.S. Provisional Patent Application No.63/089,517, filed Oct. 8, 2020, and entitled “Content Management Systemsand Methods,” and to U.S. Provisional Patent Application No. 63/105,070,filed Oct. 23, 2020, and entitled “Content Management Systems andMethods.” The contents of each of the foregoing applications areincorporated herein by reference in their entireties.

COPYRIGHT AUTHORIZATION

Portions of the disclosure of this patent document may contain materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the U.S. Patent and TrademarkOffice patent file or records, but otherwise reserves all copyrightrights whatsoever.

SUMMARY

The present disclosure relates generally to systems and methods formanaging electronic content and associated rights. More specifically,but not exclusively, the present disclosure relates to systems andmethods for providing trust in a content management ecosystem.

A number of parties and/or entities may interact in a data managementand/or processing ecosystem. For example, data providers may generatedata, aggregate data, and/or provide data to one or more other systemsand/or services. Data processors may perform various operations onand/or using data to generate new, processed, and/or derived data sets.For example and without limitation, data processors may clean and/orfilter data, reformat data, anonymize data, and/or generate otherderived and/or aggregated datasets. In this manner, data processors mayadd certain value to associated data from the perspective of dataconsumers.

Data consumers may purchase and/or otherwise access data managed by adata management platform and/or an associated data marketplace for usein a variety of contexts. Data owners, providers, processors, and/orother stakeholders may have an interest in ensuring that data usage,access, and/or distribution is governed securely. In addition, dataconsumers may be interested in ensuring the data that they consume isauthentic and/or otherwise can be trusted. Conventional datamarketplaces, however, may not provide robust and/or trusted mechanismsfor verifying the integrity, provenance, and/or chain-of-handling ofdata.

Embodiments of the disclosed systems and methods provide for a trusteddata management architecture that may allow for data providers and/orprocessors to securely record information relating to data provenanceand/or chain-of-handling. Data consumers may access and/or use suchrecorded information to authenticate and/or other verify the provenance,chain-of-handling, and/or other assertions relating to data. Recordedinformation relating to data, which may in certain instances be referredto herein as assertions, data assertions, trusted assertions, and/orderivatives thereof, may be securely recorded by a trusted assertionservice that may interact with data consumers in connection with dataverification processes.

In various embodiments, a trusted data management architecture may beimplemented, at least in part, using a trusted data management platformand/or multiple trusted data management platforms. The trusted datamanagement platform may ingest original data generated and/or otherwiseprovided by a data provider. Assertions associated with the originaldata may be recorded with a trusted assertion service by the dataprovider and/or the trusted data management platform. In someembodiments, the assertions associated with the original data may becryptographically signed with a key associated with the data providerand/or a key associated with the trusted data management platform,thereby creating a trusted cryptographic association between therecorded assertion and/or the particular data provider and/or trusteddata management platform.

One or more data processors may provide one or more programs to thetrusted data management architecture that may be configured to operateon, transform, and/or otherwise process data within the trusted datamanagement architecture to generate processed data sets. In variousembodiments, assertions associated with the processed data sets may berecorded with the trusted assertion service by the trusted datamanagement platform and/or the associated data processor. Data consumersmay access the assertions recorded by the trusted assertion service toauthenticate and/or otherwise verify the provenance, chain-of-handling,and/or other information associated with original and/or processed datasets accessed from the trusted data management platform and/orassociated data marketplaces.

Although various embodiments are described herein as having assertionsbeing generated and transmitted to a trusted assertion service from oneor more trusted data management platforms, it will be appreciated thatvarious processes, including assertion recordation and verificationprocesses, may in further embodiments be performed directly by dataproviders, processors, and/or consumers.

In some embodiments, a method for managing electronic data performed bya trusted data management platform may include accessing a first dataset and processing the first data set using a data processing programexecuting within a secure execution environment of the trusted datamanagement platform to generate a second data set (e.g., in response toa request from an associated service). In some embodiments, the firstdata set may be received from a data provider system. The dataprocessing program may be received from a data processing serviceseparate from the trusted data management platform for execution withinthe secure execution environment of the platform.

Fact information associated with the second data set may be generatedand stored. The fact information may comprise, for example and withoutlimitation, one or more of a hash of the first data set, a hash of thesecond data set, identification information associated with the dataprocessing program and/or the data processing service, a hash of thedata processing program, a timestamp associated with the generation ofthe second data set by the data processing program, configurationinformation associated with the generation of the second data set by thedata processing program, and/or information describing at least one datatransformation operation performed by the data processing program. Insome embodiments, the fact information may be securely stored with thesecond data set or in a separate database from the second data set bythe trusted data management platform.

An assertion may be generated based on the fact information. In someembodiments, assertion may comprise, for example and without limitation,one or more of a hash of the fact information, a digital signaturegenerated using a first cryptographic key securely associated with thetrusted data management platform, a digital signature generated using asecond cryptographic key securely associated with the data processingservice and/or a digital signature generating using a thirdcryptographic key securely associated with the data processing program.The platform may transmit the generated assertion to a trusted assertionservice separate from the platform for recordation.

In certain embodiments, the trusted data management platform may exposea data marketplace interface to a data consumer system. The platform mayreceive a data request from the data consumer system for the second dataset. In response to this request (e.g., after authenticating anyrequisite rights), the platform may transmit the second data set and thefact information to the data consumer system.

Various aspects of the disclosed systems and methods may be further beused in connection with managing data that includes electronic contentand/or related data and/or associated rights. Electronic content maycomprise, for example and without limitation, audio, video, written,and/or image content. Content generators, owners, and/or other partieshaving rights to content including may have an interest in ensuring thatrights to their content and/or associated data are respected. Contentpublishers and/or other entities participating in a content ecosystem(e.g., a performance rights organization (“PRO”)) may be interested inensuring that the content they publish and/or otherwise interact with isauthentic and that they respect the rights of content generators,owners, and/or other parties having interests in the content. Contentconsumers may share similar interests in ensuring that the content theyconsume is authentic and that rights of various participants in thecontent ecosystem are respected.

Embodiments of the disclosed systems and methods may provide robustand/or trusted mechanisms for managing content and/or verifying theintegrity, provenance, and/or chain-of-handling of content and/orassociated data. In various embodiments, a content creator and/or otherentity having certain rights to content may interact with trusted datamanagement platform and/or multiple trusted data management platforms tosecurely register information regarding their associated content rights.For example, in some embodiments, a trusted data management platform maygenerate secure bindings and/or associated hash bindings associatingcontent, content metadata and/or other associated information, contentand/or content rightsholder (e.g., a content creator) identificationinformation, and/or timestamp information. The secure bindings and/orassociated hash bindings may be recorded (e.g., recorded as anassertion) with a trusted assertion service maintaining a ledger ofassociated bindings and/or hash bindings.

Parties interested in verifying the integrity, provenance, and/orchain-of-handling of content and/or associated data may query thetrusted assertion service to determine whether certain bindings and/orhash bindings are recorded in the ledger. For example, in someembodiments, a PRO may interact with the trusted data managementplatform to identify whether certain assertions associated with contenthave been recorded by the trusted assertion service and ascertaininformation relating to rights associated with content. In variousfurther embodiments, a digital rights management (“DRM”) service mayinteract with the trusted data management platform and/or the trustedassertion service to verify and/or otherwise manage rights associatedwith content.

BRIEF DESCRIPTION OF THE DRAWINGS

The inventive body of work will be readily understood by referring tothe following detailed description in conjunction with the accompanyingdrawings, in which:

FIG. 1 illustrates an example of a data management architectureconsistent with various embodiments of the present disclosure.

FIG. 2 illustrates an example of a data management architectureimplementing a trusted data management platform consistent with variousembodiments of the present disclosure.

FIG. 3 illustrates an example of a data management architectureimplementing a plurality of trusted data management platforms consistentwith various embodiments of the present disclosure.

FIG. 4 illustrates an example of recording assertions and/or other factinformation associated with data with a trusted assertion serviceconsistent with various embodiments of the present disclosure.

FIG. 5 illustrates an example of a data management architecture forrecording assertions associated with data and/or processed data with atrusted assertion service consistent with various embodiments of thepresent disclosure.

FIG. 6 illustrates an example of a data verification process consistentwith various embodiments of the present disclosure.

FIG. 7 illustrates a flow chart of an example of a method for generatingand/or recording assertion information with a trusted assertion serviceconsistent with various embodiments of the present disclosure.

FIG. 8 illustrates a flow chart of an example of a method for verifyinginformation associated with data and/or processed data sets using atrusted assertion service consistent with various embodiments of thepresent disclosure.

FIG. 9A illustrates a first part of an example of a process ofregistering content and/or associated rights using a trusted datamanagement platform and/or a trusted assertion service consistent withvarious embodiments of the present disclosure.

FIG. 9B illustrates a second part of an example of a process forregistering content and/or associated rights using a trusted datamanagement platform and/or a trusted assertion service consistent withvarious embodiments of the present disclosure.

FIG. 10A illustrates a first part of an example of a process forverifying rights associated with content involving a PRO consistent withvarious embodiments of the present disclosure.

FIG. 10B illustrates a second part of an example of a process forverifying rights associated with content involving a PRO consistent withvarious embodiments of the present disclosure.

FIG. 11A illustrates a first part of an example of a content managementprocess involving a DRM service consistent with various embodiments ofthe present disclosure.

FIG. 11B illustrates a second part of an example of a content managementprocess involving a DRM service consistent with various embodiments ofthe present disclosure.

FIG. 12A illustrates a first part of an example of a key managementprocess consistent with various embodiments of the present disclosure.

FIG. 12B illustrates a second part of an example of a key managementprocess consistent with various embodiments of the present disclosure.

FIG. 13 illustrates a flow chart of an example of a method for managingelectronic content by a trusted data management platform consistent withvarious embodiments of the present disclosure.

FIG. 14 illustrates an example of a system that may be used to implementcertain embodiments of the systems and methods of the presentdisclosure.

DETAILED DESCRIPTION

A description of the systems and methods consistent with embodiments ofthe present disclosure is provided below. While several embodiments aredescribed, it should be understood that the disclosure is not limited toany one embodiment, but instead encompasses numerous alternatives,modifications, and equivalents. In addition, while numerous specificdetails are set forth in the following description in order to provide athorough understanding of the embodiments disclosed herein, someembodiments can be practiced without some or all of these details.Moreover, for the purpose of clarity, certain technical material that isknown in the related art has not been described in detail in order toavoid unnecessarily obscuring the disclosure.

The embodiments of the disclosure may be understood by reference tocertain drawings. The components of the disclosed embodiments, asgenerally described and/or illustrated in the figures herein, could bearranged and designed in a wide variety of different configurations.Thus, the following description of the embodiments of the systems andmethods of the disclosure is not intended to limit the scope of thedisclosure, but is merely representative of possible embodiments of thedisclosure. In addition, the steps of any method disclosed herein do notnecessarily need to be executed in any specific order, or evensequentially, nor need the steps be executed only once, unless otherwisespecified.

Embodiments of the disclosed systems and methods provide for a trusteddata management architecture that may allow for data providers and/orprocessors to securely record information relating to data provenanceand/or chain-of-handling, while also allowing for data consumers toauthenticate and/or otherwise validate data they receive using suchinformation in a trusted manner. Various aspects of the disclosedembodiments may, in some instances, be implemented using one or moretrusted data management platforms.

A trusted data management platform may establish trusted relationshipswith various data ecosystem stakeholders including, for example andwithout limitation, one or more data providers, data processors, trustedassertion services, data marketplace services, and/or data consumers.Various information associated with generated and/or processed dataand/or datasets may be recorded with a trusted assertion service,allowing data consumers to later use such recorded information inconnection with data authentication and/or validation activities.

FIG. 1 illustrates an example of a data management architecture 100consistent with various embodiments of the present disclosure. Asillustrated, a data provider 102 (and/or a system associated with a dataprovider) may generate and/or otherwise provide data for ingestion intothe data management architecture 100. In various examples describedherein and illustrated in the figures, data provided by a data provider102 may be generally referred to as original data and/or raw data.Although described herein as original data, such data may generallycomprise any data provided by a data provider 102 for inclusion withinthe data management architecture 100 and may not necessarily be rawand/or otherwise unprocessed data. For example, original data providedby the data provider 102 may comprise data that has been processed insome manner by the data provider 102 and/or one or more other entities.

In some embodiments, the data provider 102 may generate the originaland/or raw data. In further embodiments, the original data may begenerated by another entity and/or another data provider and may beprovided to the data provider 102 for aggregation and/or ingestion intothe data management architecture 100.

A variety of types and/or formats of data may be used in connection withvarious aspects of the disclosed embodiments including, for example andwithout limitation, various system and/or sensor data, user relateddata, personal data, health data, environmental data, business data,and/or any other type and/or types of data in any suitable format.Accordingly, it will be appreciated that the term “data” and/or “dataset” as used herein should not be considered as being limited to aparticular type and/or format of data, but may instead encompasses awide variety of types of data in a wide variety of data formats.

One or more data processing services 104 a, 104 b may be interested inprocessing the original data and/or data derived from the original datato generate processed data and/or associated data sets. For example, asillustrated, a first data processing service 104 a may use a first dataprocessing program 106 a to process the original data and generatecorresponding first processed data. Similarly, a second data processingservice 104 b may use a second data processing program 106 b to furtherprocess the first processed data to generate second processed data.

Although the illustrated examples show two data processing services 104a, 104 b and/or associated data processing programs 106 a, 106 bconfigured to generate two corresponding processed data sets, it will beappreciated that any suitable number of data processing services 104 amay engage in connection with various aspects of the disclosed datamanagement ecosystem using any suitable number of data processingprograms generating any number of process data sets. For example andwithout limitation, a single data processing service may be associatedwith and/or use multiple data processing programs. Moreover, in variousembodiments, a single data processing program may operate on data (e.g.,original and/or previously processed data) to generate multipleprocessed data sets. Therefore, it will be appreciated that variousaspects of the illustrated ecosystems and/or architectures includedherein are provided for purposes of illustration and explanation and notlimitation.

Consistent with various aspects of the disclosed embodiments, dataprocessing programs 106 a, 106 b may perform a variety of dataprocessing activities, operations, and/or actions including, for exampleand without limitation, one or more:

-   -   Data Filtering Operations—Data may be filtered in a variety of        ways including, for example and without limitation, by filtering        out and/or otherwise eliminating certain data fields, data        types, data records, and/or data ranges and/or filtering data to        include certain specified data fields, data types, data records,        and/or data ranges.    -   Data Reformatting Operations—Data and/or associated fields may        be formatted. For example and without limitation, data may be        reformatted to different file formats and/or data fields may be        reformatted to different formatting conventions (e.g., changing        temperature data from Celsius to Fahrenheit, changing date        fields from month-day-year format to day-month-year format,        and/or the like).    -   Data Transformation Operations—Data may be transformed by        applying one or more transformation operations to data. For        example and without limitation, data may be transformed using        proprietary, non-proprietary, and/or standardized algorithms        and/or transformation operations.    -   Data Anonymization Operations—Certain data may comprise        personally identifiable information and/or other sensitive        information relating to individuals (e.g., health data). Such        personally identifiable information and/or otherwise sensitive        and/or personal information may be anonymized by, for example        and without limitation, filtering out certain personal and/or        sensitive data fields, adding noise to the data to generate        anonymized data and/or associated data sets, and/or the like.    -   Derived Data Generation Operations—Data may be transformed        and/or otherwise enhanced to generate derived data and/or        associated data sets. In some embodiments, data may be combined        and/or aggregated with other data and/or data sets to generate        derived data. In further embodiments, one or more visualizations        and/or other information may be generated based on data and/or        associated data sets.

It will be appreciated that the above data processing activities,operations, and/or actions are to be viewed non-limiting examples, andthat any data processing action, operation, and/or activity, and/orcombinations thereof where data is transformed, enhanced, and/orotherwise changed may be used in connection with various embodiments.Moreover, certain types of data processing activities, operations,and/or actions may not necessarily transform data, but may enhanceand/or add value to a dataset. For example, a data processing programmay not necessarily transform data, but may validate and/or authenticatedata received from a data provider and/or other previously processeddata, resulting in validated and/or authenticated dataset (e.g., adataset signed by a cryptographic key indicating that the data in thedata set has been validated by the data processing service). In variousinstances herein, any activity, operation, and/or action performed by adata processing service 104 a, 104 b, and/or an associated program 106a, 106 b, including any of the examples detailed above, may be referredto generally herein as a data processing operation.

Consistent with embodiments disclosed herein, a data consumer system 108may wish to access and/or otherwise use data generated by the dataprovider 102 and/or processed by data processing services 104 a, 104 b.For example, as illustrated a data consumer system 108 may accessprocessed data generated by data processing program 106 b. The dataconsumer system 108 may use accessed data and/or associated data sets ina variety of contexts. For example, in some embodiments, the dataconsumer system 108 may use one or more visualization engines and/ordashboards to visualize, understand, and/or otherwise interact withaccessed data.

In some embodiments, the data consumer system 108 may authenticate itsrights to access data and/or associated datasets. For example, althoughnot specifically illustrated in connection with FIG. 1 , in someembodiments the data consumer system 108 may purchase and/or otherwiseauthenticate access to data via a data marketplace service and/or anassociated system and/or service. As discussed in more detail below, insome embodiments, such a data marketplace service may be associated withand/or otherwise implemented by a trusted data management platform.

In certain instances, there may be several potential points of attack inthe illustrated architecture 100 for a malicious party to intervene,steal, data, modify data, and/or engage in other nefarious activities.To mitigate the potential for such attacks, a variety of techniques maybe employed to enhance the security of the architecture 100 and/orvarious entities and/or stakeholders. For example, in some embodiments,secure communication channels between the various entities may beestablished (e.g., such channels employing protocols such as TransportLayer Security (“TLS”) and/or Secure Sockets Layer (“SSL”)). In furtherembodiments, password and/or other credential-based authenticationbetween the various entities and/or stakeholders may be used toestablish security and/or trust. In yet further embodiments,non-password secure communication techniques may be applied. Forexample, endpoint secrets may be protected using whitebox cryptographicmethods and/or by employing trusted execution environments (“TEEs)and/or other secure processing environments and/or techniques. In someembodiments, to enable non-password administrative addressing to anendpoint, biometric authentication (e.g., authentication using Fast IDOnline (“FIDO”) protocol) may be used that may further protect endpointsecrets with whitebox cryptographic methods and/or TEEs and/or othersecure processing environments.

Consistent with various embodiments disclosed herein, a trusted datamanagement platform that in some embodiments may implement DRMtechniques, may be used to protect data, associated processed data,and/or the interests of various data stakeholders. FIG. 2 illustrates anexample of a data management architecture 200 implementing a trusteddata management platform 202 consistent with various embodiments of thepresent disclosure.

In certain embodiments, a trusted data management platform 202 mayimplement and/or provide a trusted environment where data from one ormore data providers 102 may be ingested, accessed, managed, processed,and/or distributed. In certain embodiments, the trusted data managementplatform 202 may implement various DRM techniques to protect associateddata and/or processed data and/or manage the processing, use, access,and/or distribution of such data.

A data provider 102 may provide the trusted data management platform 202with original data. In some embodiments, the data provider 102 may havea trusted relationship with the trusted data management platform 202whereby the data provider 102 trusts that the trusted data managementplatform 202 will store, manage, process, use, and/or otherwisedistribute the provided data in a particular manner and/or in accordancewith one or more policies and/or requirements articulated by the dataprovider 102.

In some embodiments, the trusted data management platform 202 mayprovide a platform for one or more data processing programs 106 a, 106 bto operate on data and/or otherwise generate processed data and/orassociated data sets. For example, a first data processing service 104 amay provide the trusted data management platform 202 with a first dataprocessing program 106 a. The first data processing program 106 a mayexecute within a protected and/or otherwise secure execution environment(e.g., a TEE) of the trusted data management platform 202 to processoriginal data provided by the data provider 102 to the platform 202 andgenerate first processed data. In some embodiments, the execution of thefirst data processing program 106 a may proceed in accordance with oneor more policies and/or requirements articulated by one or morestakeholders (e.g., the data provider 102, the first data processingservice 104 a, a data consumer system 108, and/or the like) as enforcedby the trusted data management platform 202.

Similarly, a second data processing service 104 b may provide thetrusted data management platform 202 with a second data processingprogram 106 b. The second data processing program 106 b may executewithin the protected and/or otherwise secure execution environment ofthe trusted data management platform 202 to process the first processeddata and generate second processed data. Like the first data processingprogram 106 a, the second data processing program 106 b may proceed inaccordance with one or more policies and/or requirements articulated byone or more of the stakeholders (e.g., the data provider 102, the firstdata processing service 104 a, the second data processing service 104 b,the data consumer system 108, and/or the like) as enforced by thetrusted data management platform 202.

In some embodiments, instead of executing within a protected and/orsecure execution environment of the trusted data management platform202, one or more of the data processing programs 106 a, 106 b may beexecuted locally by the associated data processing services 104 a, 104 busing data (e.g., original data and/or processed data) accessed from thetrusted data management platform 202. For example, in someimplementations, a data processing service 104 a, 104 b may retrievedata from the trusted data management platform 202 (e.g., afterauthenticating rights to access the data with the trusted datamanagement platform 202), process the data locally using one or moreassociated data processing programs 106 a, 106 b, and provide resultingprocessed data to the trusted data management platform 202 for storageand/or management.

A data consumer system 108 may access various data, including processeddata, from the trusted data management platform 202 and/or anotherassociated system and/or service such as data marketplace service. Incertain embodiments, prior to allowing access to data and/or processeddata, a data consumer system 108 may be required to authenticate itsrights to access and/or otherwise use the data and/or processed datawith the trusted data management platform 202 and/or an associatedservice.

In some embodiments, the trusted data management platform 202 maycomprise a data marketplace service that may allow a data consumersystem 108 to interact with, purchase, and/or otherwise access dataand/or processed data and/or subsets thereof managed by the trusted datamanagement platform 202. In further embodiments, a data marketplaceservice separate from the trusted data management platform 202 may beused. In some embodiments, the trusted data management platform 202 mayprovide data and/or processed data to such a separate data marketplacefor distribution to authenticated data consuming systems. In furtherembodiments, a separate data marketplace service may function as anintermediary facilitating data transactions between a data consumersystem 108 and one or more trusted data management platforms 202.

Although the example data management architecture 200 illustrated inconnection with FIG. 2 includes a single trusted data managementplatform, it will be appreciated that a plurality of data managementplatforms may be included in further implementations consistent withvarious embodiments disclosed herein. FIG. 3 illustrates an example of adata management architecture 300 implementing a plurality of trusteddata management platforms 302 a, 302 b consistent with variousembodiments of the present disclosure.

As shown in FIG. 3 , a first trusted data management platform 302 a mayreceive data from a data provider 102. The first trusted data managementplatform 302 a may further process the original data received from thedata provider 102 using a first data processing program 106 a providedto the first trusted data management platform 302 a by a first dataprocessing service 104 a to generate first processed data. The firstprocessed data may be securely shared by the first trusted datamanagement platform 302 a with a second trusted data management platform302 b (e.g., shared via a secure communication channel). The secondtrusted data management platform 302 b may further process the firstprocessed data received from the first trusted data management platform302 a using a second data processing program 106 b to generate secondprocessed data. The data consumer system 108 may access the secondprocessed data from the second trusted data management platform 302 band/or a data marketplace service associated with the second trusteddata management platform 302 b. In this manner, a plurality of trusteddata management platforms 302 a, 302 b may be used to protect, manage,and/or process data in the illustrated data management architecture 300.

Certain conventional data management ecosystems may be associated withcertain issues from the perspective of a data consumer. For example, adata consumer may not be certain what parties, services, and/or entitiespreviously processed the data they access and/or how such data wasprocessed. A data consumer may in certain circumstances, for example,only be able to obtain information from a platform in which they aredirectly interacting and not be able to obtain information regardingdata processing by other parties earlier in the data chain-of-custody.Moreover, a data consumer may not necessarily be certain which partiesprocessed an earlier version of a dataset, which may be especially truewhen an earlier dataset was generated by a data platform with which thedata consumer did not directly interact. Finally, a data consumer maynot be certain as to what party originally generated a dataset, whichagain may be especially true when the original data provider did notdirectly interact with the data consumer.

Embodiments of the disclosed systems and methods may help amelioratesome and/or all of these issues through a trusted mechanism for securelyrecording trusted assertions and/or other fact information associatedwith data in a data management architecture. FIG. 4 illustrates anexample of recording assertions and/or other fact information associatedwith data with a trusted assertion service 400 consistent with variousembodiments of the present disclosure. Specifically, FIG. 4 illustratesrecording of assertion and/or other fact information associated withdata provided to a trusted data management platform 202 by a dataprovider 102.

When a data provider 102 generates data (e.g., original data) and/orprocesses data, it may also generate certain information associated withthe data that, in certain instances herein, may be referred to as factinformation and/or a “fact” associated with the data. Fact informationmay comprise a variety of information relating to the associated dataand/or its provenance. For example and without limitation, factinformation associated with original data provided to the trusted datamanagement platform 202 by the data provider 102 may comprise one ormore of a ID of the data provider 102, a time stamp associated with thedata (e.g., a time stamp associated with the generation of the data bythe data provider 102 and/or another data service, the ingestion of thedata into the trusted data management platform 202, and/or the like), ahash of the associated data and/or a portion thereof, an indication of afunction used to generate the hash, an indication of any portion of dataused to generate the hash and/or other information relating to thegeneration of the hash, a geolocation associated with the data provider102 and/or the generation of the data, configuration and/or conditioninformation relating to the data (e.g., configuration informationregarding how the data was generated, collected, formatted, and/or thelike), and/or description and/or other information associated with thedata (e.g., metadata such as data type and/or the like).

The fact information and/or associated data may be communicated to thetrusted data management platform 202 by the data provider 102. In someembodiments, the fact information may be communicated to the trusteddata management platform 202 separately from the associated data. Infurther embodiments, the fact information may be communicated to thetrusted data management platform 202 in a package that also includes theassociated data. The trusted data management platform 202 may store thefact information together with the associated data and/or in a separatedatabase used to manage fact information associated with data managed bythe trusted data management platform 202.

Consistent with various embodiments disclosed herein, the data provider102 may communicate an assertion relating to the data provided to thetrusted data management platform 202 to a trusted assertion service 400.In certain embodiments, the assertion may comprise the fact informationassociated with the data and/or the hash of the fact information and/ora portion thereof. The assertion may further be signed with a keyassociated with the data provider 102.

Upon receipt of the assertion, the trusted assertion service 400 mayverify the signature associated with the assertion to determine whetherthe data provider 102 is a legitimate and/or otherwise trusted entity.For example, in certain embodiments, the trusted assertion service 400may determine that an authority associated with a key used to generatethe signature by the data provider 102 is current and/or otherwise hasnot been revoked. In some embodiments, the trusted assertion service 400may interact with a separate authentication service to authenticate thesignature of the data provider 102 associated with the assertion.

If the trusted assertion service 400 successfully verifies the signaturein the assertion (e.g., confirming that the data provider 102 is alegitimate and/or otherwise trusted entity), the fact information and/orthe hash of the fact information and/or a portion thereof may berecorded by the trusted assertion service 400. The trusted assertionservice 400 may store the fact information and/or the hash of the factinformation and/or a portion thereof in a database and/or ledger. Insome embodiments, the fact information and/or hash of the factinformation may be securely recorded in a trusted immutable assertionledger that, in some implementations, may comprise a trusted immutabledistributed assertion ledger (“TIDAL”). In various embodiments, a ledgerused to record the fact information and/or hash of the fact informationmay implement ledger processes that may be resistant to byzantinefailures, entries that may be immutable and/or relatively immutable,entries that may be time-synced (at least in part), entries that may bescalable, and/or entries that may be available for relatively fastlookup. In certain embodiments, assertion ledgers, including TIDALS, mayemploy various blockchain technologies.

Fact information and/or hashes of fact information and/or portionsthereof recorded by the trusted assertion service 400 in the associateddatabase and/or ledger may be used in connection with verifying theintegrity, provenance, and/or chain-of-handling of data. For example, asdiscussed in more detail below, a data consumer system may query thetrusted assertion service 400 to identify whether certain information isincluded the database and/or ledger, providing a trusted mechanism forthe data consumer system to verify the integrity, provenance, and/orchain-of-handling of data.

In certain embodiments, data provided to and/or otherwise accessed bythe trusted data management platform 202 from the data provider 102 maybe supplemented by the trusted data management platform 202 and/or oneor more data processing programs associated with and/or executing on theplatform 202 (e.g., programs executing within a secure and/or protectedenvironment of the platform 202). For example, in some embodiments,timestamp and/or unique data ID information may be added to dataprovided to and/or otherwise accessed by the trusted data managementplatform 202 that may allow a data consumer to use these supplementalvalues and/or information when querying data (e.g., querying data usingthe unique data ID information). In some embodiments, such informationmay be added by the data provider 102 itself, the trusted datamanagement platform 202, and/or one or more data processing servicesand/or associated data processing programs.

Assertions relating to the generation and/or processing of data may berecorded with a trusted assertion service 400 at a variety of stagesduring the chain-of-handling of the data. For example, FIG. 5illustrates an example of a data management architecture 500 forrecording assertions associated with data and/or processed data with atrusted assertion service 400 consistent with various embodiments of thepresent disclosure.

Data generated by a data provider 102 may be communicated to a trusteddata management platform 202 for storage and/or management by theplatform 202. As discussed above, the data provider 102 may alsogenerate fact information associated with the data that may comprise,for example and without limitation, one or more of a ID of the dataprovider 102, a time stamp associated with the data (e.g., thegeneration of the data), a hash of the associated data and/or a portionthereof, an indication of a function used to generate the hash, anindication of any portion of data used to generate the hash and/or otherinformation relating to the generation of the hash, a geolocationassociated with the data provider 102 and/or the generation of the data,condition information associated with the data, and/or descriptionand/or other information associated with the data (e.g., metadata). Thedata provider 102 may communicate such fact information to the trusteddata management platform 202 together with and/or separate from theassociated data for storage. In further embodiments, instead of factinformation being generated by the data provider 102, the factinformation and/or aspects thereof may be generated by the trusted datamanagement platform 202 upon receipt of the data from the data provider102.

In various disclosed embodiments, the data provider 102 may communicatean assertion to a trusted assertion service 400 relating to the dataprovided to trusted data management platform 202. The assertion maycomprise, for example and without limitation, one or more of the factinformation associated with the data, a hash of the fact informationand/or a portion thereof, and/or a digital signature. In someembodiments, the digital signature may comprise a signature over theassertion and/or a part of the assertion with a key associated with thedata provider 102. In this manner, the signature may securely associatethe assertion and/or its constituent information with the data provider102.

Upon receipt of the assertion, the trusted assertion service 400 mayverify and/or otherwise authenticate the signature associated with theassertion to determine whether the data provider 102 is a legitimateand/or otherwise trusted entity. If the trusted assertion service 400successfully verifies the signature, thereby confirming that the dataprovider 102 is a legitimate and/or otherwise trusted entity, the factinformation and/or the hash of the fact information and/or a portionthereof included in the assertion may be recorded by the trustedassertion service 400. As discussed above, the trusted assertion service400 may store the fact information and/or the hash of the factinformation and/or a portion thereof in a database and/or ledger thatmay comprise a trusted immutable assertion ledger 502.

Although the embodiments shown in FIG. 5 illustrate the assertion beinggenerated by the data provider 102 and communicated directly from thedata provider 102 to the trusted assertion service 400, it will beappreciated that other implementations are also possible. For example,in some embodiments, the assertion and/or its constituent information(e.g., fact information and/or a hash of the fact information and/or aportion thereof) may be generated by the data provider 102 andcommunicated to the trusted data management platform 202. The trusteddata management platform 202 may communicate the assertion and/orconstituent information to the trusted assertion service 400 for securerecordation (e.g., after verifying a signature by the data provider 102over the assertion and/or a part of the assertion and/or the like). Inyet further embodiments, the trusted data management platform 202 maygenerate the assertion and/or its constituent information (e.g., factinformation and/or a hash of the fact information and/or a portionthereof) rather than the data provider 102 itself.

In further embodiments, instead of or in addition to being signed by akey securely associated with the data provider 102, an assertion and/orits constituent information may be signed using a secure key associatedwith the trusted data management platform 202 before being communicatedto the trusted assertion service 400 for secure recordation. Uponreceipt of the signed assertion from the trusted data managementplatform 202, the trusted assertion service 400 may verify and/orotherwise authenticate one or more signatures associated with theassertion to determine whether the assertion has been signed by alegitimate and/or otherwise trusted entity.

For example, in some embodiments, as discussed above, the trustedassertion service 400 may verify and/or otherwise authenticate asignature by the data provider 102 to determine whether the dataprovider 102 is a legitimate and/or otherwise trusted entity. Inaddition to or in lieu of verifying a signature on a received assertionby the data provider 102, the trusted assertion service 400 may verify asignature by the trusted data management platform 202 on a receivedassertion.

In some embodiments, the trusted assertion service 400 may rely on anyassertion received from and signed by the trusted data managementplatform 202 as being trusted. Accordingly, the trusted assertionservice 400 may perform authentication check on the signature on theassertion by the trusted data management platform 202 but notnecessarily a signature on the assertion by the data provider 102. Infurther embodiments, signatures on the assertion from both the from thedata management platform 200 and the data provider 102 may beauthenticated. Although not specifically illustrated, the trustedassertion service 400 may interact with a separate authenticationservice in connection with authenticating various signatures onassertions (e.g., signatures by the data provider 102, the trusted datamanagement platform 202, and/or one or more data processing services 104a, 104 b, as described in more detail below).

If the trusted assertion service 400 successfully verifies that thesignatures from the data provider and/or the trusted data managementplatform 202 are legitimate, the fact information and/or hash of thefact information and/or portion thereof may be recorded by the trustedassertion service 400 in a database and/or ledger 502. In certainembodiments, the recorded fact information and/or hash of the factinformation and/or portion thereof may be recorded as a timestampedentry in the database and/or ledger 502.

In certain embodiments, one or more data processing services 104 a, 104b may be interested in processing the data provided to the trusted datamanagement platform 202 and/or data derived therefrom to generateprocessed data and/or associated data sets. For example, as illustrated,a first data processing service 104 a may use a first data processingprogram 106 a to process the original data received by the trusted datamanagement platform 202 by the data provider 102 and generatecorresponding first processed data.

In some embodiments, the first data processing service 104 a maytransmit the first data processing program 106 a to the trusted datamanagement platform 202 to operate on data within a protected and/orsecure execution environment of the trusted data management platform202. In certain embodiments, the first data processing service 104 a maynot necessarily communicate the first data processing program 106 a tothe trusted data management platform 202, but may select the first dataprocessing program 106 a to operate on data using standard datatransformation and/or processing libraries and/or the like offered bythe trusted data management platform 202 and/or an associated serviceand/or coordinate the provisioning of the first data processing program106 a to the trusted data management platform 202 via one or more otherservices. In further embodiments, instead of executing with a protectedand/or secure execution environment of the trusted data managementplatform 202, the first data processing program 106 a may be executedlocally by the first data processing service 104 a using data accessedfrom the trusted data management platform 202.

When the first data processing program 106 a processes the data receivedfrom the data provider 102 to generate the first processed data, factinformation may also be generated. In some embodiments, the first dataprocessing program 106 a may generate the fact information. In furtherembodiments, the protected and/or secure execution environment of thetrusted data management platform 202 may be used to generate the factinformation when the first data processing program is executed tooperate on data within the protected and/or secure executionenvironment. In yet further embodiments, the fact information may begenerated by the first data processing service 104 a, which may executethe first data processing program 106 a locally and/or call the trusteddata management platform 202 to execute the first data processingprogram 106 a as described above.

Fact information associated with the first processed data may include,for example and without limitation, one or more of:

-   -   ID information associated with the first data processing service        104 a.    -   ID information associated with the first data processing program        106 a.    -   A hash of the original data operated on by the first data        processing program 106 a and/or a portion thereof.    -   A hash of the first processed data generated by the first data        processing program 106 a and/or a portion thereof.    -   A hash of the first data processing program 106 a and/or a        portion thereof.    -   Hash generation information that may indicate, for example and        without limitation, one or more hash functions used to generate        the hash of the original data and/or the portion of the original        data, the hash of the first processed data and/or the portion of        the first processed data, and/or the hash of the first data        processing program and/or the portion of the first data        processing program. The hash generation information may further        comprise an indication of any portion of data and/or program        used to generate the hashes and/or other information relating to        the generation of the hashes. In some embodiments, the hash        generation information may further comprise an indication of a        hash function and/or associated parameters used to generate        hashed fact information recorded by the trusted assertion        service 400.    -   Timestamp information associated with the original data and/or        the first processed data (e.g., a time stamp associated with the        generation of the original data and/or uploading of the original        data to the trusted data management platform 202 and/or the        generation of the first processed data by the first data        processing program 106 a).    -   Configuration and/or condition information relating to the        generation of the first processed data by the first data        processing program 106 a.    -   Description information relating to what changes and/or        processes were performed on the original data by the first data        processing program 106 a in connection with generating the first        processed data.

The trusted data management platform 202 may store the fact informationwith the associated first processed data and/or in a separate databaseused to manage fact information.

Consistent with various embodiments, an assertion relating to the firstprocessed data may be generated and/or communicated to the trustedassertion service 400 by the trusted data management platform 202 and/orthe first data processing service 104 a. In certain embodiments, theassertion may comprise the fact information associated with the firstprocessed data and/or a hash of the fact information and/or a portionthereof. In some embodiments, the assertion may be communicated to thetrusted assertion service 400 by the first data processing service 104a. In further embodiments, the assertion may be communicated to thetrusted assertion service 400 by the trusted data management platform202.

The assertion may comprise one or more signatures. For example, in someembodiments, the assertion may be signed with a key associated with thefirst data processing service 104 a, the first data processing program106 a, and/or the trusted data management platform 202. In this manner,the assertion may be securely associated with the first data processingservice 104 a, the first data processing program 106 a, and/or thetrusted data management platform 202.

Upon receipt of the signed assertion, the trusted assertion service 400may verify and/or otherwise authenticate one or more signaturesassociated with the assertion to determine whether the assertion hasbeen signed by a legitimate and/or otherwise trusted entity. Forexample, in some embodiments, the trusted assertion service 400 mayverify and/or otherwise authenticate a signature on the assertion by thefirst data processing service 104 a, the first data processing program106 a, and/or the trusted data management platform 202 to determinewhether they are legitimate and/or otherwise trusted entities. Incertain embodiments, a private key associated with the first dataprocessing program 106 a used to sign an assertion may be protected byaccess control mechanisms implemented by the trusted data managementplatform 202. In further embodiments, the private key associated withthe first data processing program 106 a may be protected using keyprotection technologies such as whitebox cryptographic protectionmethods (e.g., protections implemented by the associated data processingservice 104 a), which may protect the private key from being accessed inthe clear by the trusted data management platform 202.

In some embodiments, the trusted assertion service 400 may rely on thetrusted data management platform 202 to perform certain authenticationand/or trust determinations regarding the first data processing service104 a and/or the associated first data processing program 106 a.Accordingly, the trusted assertion service 400 may rely on any assertionreceived from and signed by the trusted data management platform 202 asbeing trusted without necessarily verifying signatures on an assertionby the first data processing service 104 a and/or the associated firstdata processing program 106 a. In further embodiments, multiplesignatures on the assertion may be verified by the trusted assertionservice 400 (e.g., signatures by the first data processing service 104a, the first data processing program 106 a, and/or the trusted datamanagement platform 202).

If the trusted assertion service 400 successfully verifies and/orauthenticates one or more signatures associated with the assertion, thefact information and/or hash of the fact information and/or portionthereof included in the assertion may be recorded by the trustedassertion service 400 in a database and/or ledger 502. In variousembodiments, the recorded fact information and/or hash of the factinformation and/or portion thereof may be recorded as a timestampedentry in the database and/or ledger 502.

As described above, in certain embodiments, data provided to and/orotherwise accessed by the trusted data management platform 202 from thedata provider 102 may be supplemented by the trusted data managementplatform 202 and/or one or more data processing programs 106 a, 106 bassociated with and/or executing on the platform 202 (e.g., programsexecuting within a secure and/or protected environment of the platform202). For example, in some embodiments, timestamp and/or unique data IDinformation may be added to data provided to and/or otherwise accessedby the trusted data management platform 202 and/or programs 106 a, 106 bthat may allow a data consumer system 108 to use these supplementalvalues and/or information when querying data (e.g., querying data usingthe unique data ID information). In some embodiments, such informationmay be added by the data provider 102 itself, the trusted datamanagement platform 202, and/or one or more data processing services 104a, 104 b and/or associated data processing programs 106 a, 106 b. Forexample, supplemental information including unique data ID informationand/or timestamp information may be added by the first processingprogram 106 a and be included in the first processed data.

When the first data processing program 106 a processes the data receivedfrom the data provider 102 to generate the first processed data, factinformation may also be generated. In some embodiments, the first dataprocessing program 106 a may generate the fact information. In furtherembodiments, the protected and/or secure execution environment of thetrusted data management platform 202 may be used to generate the factinformation when the first data processing program is executed tooperate on data within the protected and/or secure executionenvironment. In yet further embodiments, the fact information may begenerated by the first data processing service 104 a, which may executethe first data processing program 106 a locally and/or call the trusteddata management platform 202 to execute the first data processingprogram 106 a as described above.

As illustrated in FIG. 5 , a second data processing service 104 b mayfurther use a second data processing program 106 b to process the firstprocessed data to generate second processed data. In some embodiments,the second data processing service 104 b may transmit the second dataprocessing program 106 b to the trusted data management platform 202 tooperate on data within the protected and/or secure execution environmentof the trusted data management platform 202. In certain embodiments, thesecond data processing service 104 b may not necessarily communicate thesecond data processing program 106 b to the trusted data managementplatform 202, but may select the second data processing program 106 b tooperate on data using standard data transformation and/or processingprogram libraries and/or the like offered by the trusted data managementplatform 202 and/or an associated service and/or coordinate theprovisioning of the second data processing program 106 b to the trusteddata management platform 202 via one or more other services. In furtherembodiments, instead of executing with a protected and/or secureexecution environment of the trusted data management platform 202, thesecond data processing program 106 b may be executed locally by thesecond data processing service 104 b using data accessed from thetrusted data management platform 202.

When the second data processing program 106 b processes the firstprocessed data to generate the second processed data, associated factinformation may also be generated. In some embodiments, the second dataprocessing program 106 b may generate the fact information. In furtherembodiments, the protected and/or secure execution environment of thetrusted data management platform 202 may be used to generate the factinformation when the second data processing program 106 b is executed tooperate on data within the protected and/or secure executionenvironment. In yet further embodiments, the fact information may begenerated by the second data processing service 104 b, which may executethe second data processing program 106 b locally and/or by calling thetrusted data management platform 202 to execute the second dataprocessing program 106 b as described above.

Fact information associated with the second processed data may include,for example and without limitation, one or more of:

-   -   ID information associated with the second data processing        service 104 b.    -   ID information associated with the second data processing        program 106 b.    -   A hash of the first processed data operated on by the second        data processing program 106 b and/or a portion thereof.    -   A hash of the second processed data generated by the second data        processing program 106 b and/or a portion thereof    -   A hash of the second data processing program 106 b and/or a        portion thereof.    -   Hash generation information that may indicate, for example and        without limitation, one or more hash functions used to generate        the hash of the first processed data and/or the portion of the        first processed data, the hash of the second processed data        and/or the portion of the second processed data, and/or the hash        of the second data processing program and/or the portion of the        second data processing program. The hash generation information        may further comprise an indication of any portion of data and/or        program used to generate the hashes and/or other information        relating to the generation of the hashes. In some embodiments,        the hash generation information may further comprise an        indication of a hash function and/or associated parameters used        to generate hashed fact information recorded by the trusted        assertion service 400.    -   Timestamp information associated with the first processed data        and/or the second processed data (e.g., a time stamp associated        with the generation of the first processed data and/or the        generation of the second processed data by the second data        processing program 106 b).    -   Configuration and/or condition information relating to the        generation of the second processed data by the second data        processing program 106 b.    -   Description information relating to what changes and/or        processes were performed on the first processed data by the        second data processing program 106 b in connection with        generating the second processed data.

The trusted data management platform 202 may store the fact informationwith the associated second processed data and/or in a separate databaseused to manage fact information.

Consistent with various embodiments disclosed herein, an assertionrelating to the second processed data may be generated and/orcommunicated to the trusted assertion service 400 by the trusted datamanagement platform 202 and/or the second data processing service 104 b.In certain embodiments, the assertion may comprise the fact informationassociated with the second processed data and/or a hash of the factinformation and/or a portion thereof. In some embodiments, the assertionmay be communicated to the trusted assertion service 400 by the seconddata processing service 104 b. In further embodiments, the assertion maybe communicated to the trusted assertion service 400 by the trusted datamanagement platform 202.

The assertion may comprise one or more signatures. For example, in someembodiments, the assertion may be signed with a key associated with thesecond data processing service 104 b, the second data processing program106 b, and/or the trusted data management platform 202. In this manner,the assertion may be securely associated with the second data processingservice 104 b, the second data processing program 106 b, and/or thetrusted data management platform 202.

Upon receipt of the signed assertion, the trusted assertion service 400may verify and/or otherwise authenticate one or more signaturesassociated with the assertion to determine whether the assertion hasbeen signed by a legitimate and/or otherwise trusted entity. Forexample, in some embodiments, the trusted assertion service 400 mayverify and/or otherwise authenticate a signature on the assertion by thesecond data processing service 104 b, the second data processing program106 b, and/or the trusted data management platform 202 to determinewhether they are legitimate and/or otherwise trusted entities. Incertain embodiments, a private key associated with the second dataprocessing program 106 b used to sign an assertion may be protected byaccess control mechanisms implemented by the trusted data managementplatform 202. In further embodiments, the private key associated withthe second data processing program 106 b may be protected using keyprotection technologies such as whitebox cryptographic protectionmethods (e.g., protections implemented by the associated data processingservice 104 b), which may protect the private key from being accessed inthe clear by the trusted data management platform 202.

In some embodiments, the trusted assertion service 400 may rely on thetrusted data management platform 202 to perform certain authenticationand/or trust determinations regarding the second data processing service104 b and/or the associated second data processing program 106 b.Accordingly, the trusted assertion service 400 may rely on any assertionreceived from and signed by the trusted data management platform 202 asbeing trusted without necessarily verifying signatures on an assertionby the second data processing service 104 b and/or the associated seconddata processing program 106 b. In further embodiments, multiplesignatures on the assertion may be verified by the trusted assertionservice 400 (e.g., signatures by the second data processing service 104b, the second data processing program 106 b, and/or the trusted datamanagement platform 202).

If the trusted assertion service 400 successfully verifies and/orauthenticates one or more signatures associated with the assertion, thefact information and/or hash of the fact information and/or portionthereof included in the assertion may be recorded by the trustedassertion service 400 in a database and/or ledger 502. In variousembodiments, the recorded fact information and/or hash of the factinformation and/or portion thereof may be recorded as a timestampedentry in the database and/or ledger 502.

Fact information and/or hashes of fact information and/or portionsthereof recorded by the trusted assertion service 400 in the associateddatabase and/or ledger 502 may be used in connection with verifying theintegrity, provenance, and/or chain-of-handling of data. For example, asillustrated and described below in connection with FIG. 6 , a dataconsumer system 108 may query the trusted assertion service 400 toidentify whether certain information is included the database and/orledger entries, thereby providing a trusted mechanism for the dataconsumer system 108 to verify the integrity, provenance, and/orchain-of-handling of data it receives and/or otherwise accesses from thetrusted data management platform 202.

Although various illustrated examples show use of a single trustedassertion service 400, it will be appreciated that any suitable numberof trusted assertion services may be employed. For example and withoutlimitation, a first trusted assertion service may record factinformation and/or hashes of fact information and/or portions thereofrelating to original data ingested into the trusted data managementplatform 202 (e.g., original data provided by data provider 102), asecond trusted assertion service (or multiple assertion services) mayrecord fact information and/or hashes of fact information and/orportions thereof relating to processed data (e.g., first processed datagenerated by the first data processing service 104 a and/or the firstdata processing program 106 b, second processed data generated by thesecond data processing service 104 b and/or the first data processingprogram 106 b, and/or the like). Therefore, it will be appreciated thatvarious aspects of the illustrated ecosystems and/or architecturesinclude herein are to be considered as nonlimiting examples of possibleimplementations.

In some embodiments, the trusted data management platform 202 may managethe governance of one or more distributed databases and/or associateddatasets that may not be directly within and/or controlled by theplatform 202. For example, the trusted data management platform 202 maymanage data associated with one or more distributed databases and/ordatasets via one or more suitably configured application programminginterfaces (“APIs”).

FIG. 6 illustrates an example of a data verification process consistentwith various embodiments of the present disclosure. As discussed above,fact information and/or hashes of fact information and/or portionsthereof may be recorded by a trusted assertion service 400 in theassociated database and/or ledger 502. Recorded information in thedatabase and/or ledger 502 may be used in connection with verifying theintegrity, provenance, and/or chain-of-handling of data.

A data consumer system 108 may access original and/or processed datafrom a data marketplace service 600. In some embodiments, the datamarketplace service 600 may comprise a service implemented by a trusteddata management platform, and therefore may be executed by a same systemand/or service of the trusted data management platform. In someembodiments, the data marketplace service 600 may be a separate and/orotherwise independent service from a trusted data management platformconfigured to provide a marketplace dashboard for data consumers toaccess data managed by a trusted data management platform. Although inthe illustrated embodiments the data marketplace service 600 may providethe data consumer system 108 with the original and/or processed data, itwill be appreciated that in further embodiments, the data marketplaceservice 600 may operate as an intermediary in a data transaction betweena data consumer system 108 and a trusted data management platformwhereby data access is provided directly by the trusted data managementplatform.

The data consumer system 108 may further receive fact information and/ora hash of fact information and/or a portion thereof associated with theaccessed data. In some embodiments, the fact information and/or a hashof fact information and/or a portion thereof may be received togetherwith the associated data. In further embodiments, the fact informationand/or a hash of fact information and/or a portion thereof may bereceived separate from the associated data. In certain embodiments, thefact information may comprise the hash generation information (e.g., anindication of a hash function and/or associated parameters such as hashdata ranges and/or the like used to generated hashed information used inconnection with validating and/or authenticating fact information asdescribed below).

In certain embodiments, the data consumer system 108 may receive thefact information and/or a hash of fact information and/or a portionthereof from the trusted data management platform and/or a datamarketplace service 600 implemented by the trusted data managementplatform. In further embodiments, the data consumer system 108 mayreceive the fact information and/or a hash of fact information and/or aportion thereof from a data marketplace service 600 separate from atrusted data management platform.

The data consumer system 108 may wish to verify fact informationassociated with the information it accesses from the data marketplaceservice 600 and/or an associated trusted data management platform. Forexample, the data consumer system 108 may receive processed data andassociated fact information and may wish to verify the accuracy of thefact information associated with the received processed data and/orlearn more about the provenance and/or chain-of-handling of theprocessed data.

To verify fact information associated with processed data, the dataconsumer system 108 may issue a data verification request 602 to atrusted assertion service 400. In some embodiments, the dataverification request 602 may comprise the fact information and/or a hashof the fact information and/or a portion thereof. In some embodiments,the hash may be generated based on hash generation information includedin the fact information. Upon receipt of the data verification request602, the trusted assertion service 400 and/or a data verification engine606 executing on the service may query a database and/or ledger 502managed by the trusted assertion service 400 to determine whether thefact information and/or the hash of the fact information and/or theportion thereof is included in the database and/or ledger 502 managed bythe trusted assertion service 400.

If the fact information and/or the hash of the fact information and/orthe portion thereof is included in the database and/or ledger 502maintained by the trusted assertion service 400, the trusted assertionservice 400 and/or the associated data verification engine 606 mayreturn a data verification response 604 to the data consumer system 108indicating that the fact information associated with the dataverification request 602 is authenticated and/or otherwise verified. Ifthe fact information and/or the hash of the fact information and/or theportion thereof is not included in the database and/or ledger 502maintained by the trusted assertion service 400, the trusted assertionservice 400 and/or the associated data verification engine 606 mayreturn a data verification response 604 to the data consumer system 108indicating that the fact information associated with the dataverification request 602 was not verified. Based on the received dataverification response 604, the data consumer system 108 may determinewhether information asserted about data accessed by the system 108reflected in associated fact information may be trusted.

In certain embodiments, a data consumer system 108 may receive factinformation and/or a hash of fact information and/or a portion thereofassociated with the data it receives from the data marketplace service600 as well as fact information and/or hashes of fact information and/orportions thereof associated with datasets earlier in thechain-of-handling of the data received from the data marketplace service600. For example, the data consumer system 108 may receive factinformation and/or a hash of the fact information and/or a portionthereof associated with processed data it receives from the datamarketplace service 600, as well as fact information and/or a hash ofthe fact information and/or a portion thereof associated with originaldata provided by a data provider that was used to generate the processeddata received by the data consumer system 108 and/or earlier processedversions of the data. In certain embodiments, using thischain-of-handling fact information, the data consumer system 108 mayascertain, for example and without limitation, one of more of how datawas originally generated, by which parties it was generated, when it wasgenerated, which parties and/or programs operated on and/or otherwiseprocessed the data, and/or the like. In some embodiments, this may bedone without necessarily exposing the earlier datasets (e.g., theoriginal data and/or earlier processed versions of the data) to the dataconsumer system 108. The data consumer system 108 may verify this factinformation relating to earlier versions of the data with the trustedassertion service 400.

In some embodiments, chained hash information included in factinformation associated with a received dataset may be used to identifyfact information associated with earlier datasets used in connectionwith generating the data received by the data consumer system 108. Forexample, in a data chain-of-handling whereby original data is processedby two data processing programs prior to being provided to a dataconsumer system 108, a hash of an intermediate data set included in factinformation associated with the final dataset may be used to identifyfact information associated with the intermediate data set (which mayalso include the same hash). A hash of the original data set included infact information associated with the intermediate data set may be usedto identify fact information associated with the original dataset (whichmay also include the hash of the original data set).

Identified fact information in the chain-of-handling of the data may beverified and/or authenticated with one or more trusted assertionservices 400. By tracing the trusted chain of custody establishedthrough the one or more trusted assertion services 400, a data consumermay be assured of, among other things, the identity of the data providerof the original dataset and the identities of data processors later inthe chain-of-handling of the data.

Although various embodiments illustrated in FIG. 6 show the dataconsumer system 108 verifying and/or authenticating fact informationassociated with a dataset through interactions with the trustedassertion service 400, it will be appreciated that other implementationsare also possible. For example, in some embodiments, the data consumersystem 108 may request data and/or verification of the data from thedata marketplace service 600 and/or a trusted data management platform.The data marketplace service 600 and/or trusted data management platformmay then submit a data verification request to the trusted assertionservice 400, receive a data verification response from the trustedassertion service 400, and may provide the data verification responseand/or an indication of data authenticity and/or integrity reflected inthe response along with the requested data to the data consumer system108.

In at least one non-limiting example, embodiments of the disclosedsystems and methods may be used in connection with a service formanaging data and/or other information with audio, video, and/or imagecontent. Content authors, creators, and/or other parties with rights tocontent may register their content with a trusted data managementplatform. In various embodiments, the content authors, creators, and/orother parties with rights to the content may operate, at least in part,as a data provider. The trusted data management platform may receive theaudio, video, and/or image content, ID information associated with thecontent author, creator, and/or other associated party with rights tothe content, as well as a signed signature and/or other access tokensecurely associated with the content author, creator, and/or otherassociated party with rights to the content.

The trusted data management platform may authenticate and/or otherwisevalidate the signature and/or other access token. A binding between thecontent, the ID information associated with the content author, creator,and/or other associated party with rights to the content, and/ortimestamp information may be generated by the trusted data managementplatform.

As used herein, a “binding” of data and/or other information maycomprise a variety of forms and/or be generated using a variety oftechniques. In some embodiments, binding of data and/or otherinformation may be performed using any technique of associating aplurality of data and/or other information. For example, an associativedata structure that associates a plurality of data and/or otherinformation may be used as a binding consistent with various aspects ofthe disclosed embodiments. In further embodiments, data and/or otherinformation may be concatenated to form a binding.

In various other embodiments, a binding may be formed using only aportion of the subject data and/or other information and/or based onsome transformation of the subject data and/or other information and/ora portions thereof. For example, in some embodiments, a binding may beformed by performing a hash operation of subject binding data and/orother information and/or a portions thereof. Thus it will be appreciatedthat, while in certain examples herein, a binding is described ascomprising subject data and/or other information, a wide variety oftypes of bindings structured and/or generated in a variety of ways maybe used without departing from the scope of the inventive body of work.

The trusted data management platform may generate a hash of the bindingand sign the hash of the binding with a secure key associated with thetrusted data management platform. The trusted data management platformmay communicate the signed hash of the binding as an assertion to thetrusted assertion service 400 for recordation.

The trusted assertion service 400 may authenticate and/or otherwisevalidate the signature associated with the received assertion inaccordance with one or more policies enforced by the trusted assertionservice 400. For example, the trusted assertion service 400 may onlyallow authenticated assertions and/or constituent information signed byparticular trusted platforms to be recorded in the trusted databaseand/or ledger 502. If the signature of the received assertion isauthentic and/or valid, the trusted assertion service 400 may record thehash of the binding in the trusted database and/or ledger 502. Thetrusted assertion service 400 may further record additional informationassociated with the recorded hash in the trusted database and/or ledger502. For example and without limitation, the trusted assertion service400 may record timestamp information associated with the hash of thebinding in the trusted database and/or ledger 502.

A data consumer system 108 such as, for example, a content publisher,may wish to receive content that has an indication and/or othercertification of its validity and/or authenticity from the datamarketplace service 600 and/or an associated trusted data managementplatform. The data consumer system 108 may issue a request to the datamarketplace service 600 and/or the associated trusted data managementplatform specifying the requesting content and/or ID informationassociated with the content author, creator, and/or other associatedparty with rights to the content. The data marketplace service 600and/or the associated trusted data management platform may generate ahash of certain information received in the request and, in someembodiments, other information retrieved from a database managed by thedata marketplace service 600 and/or the associated trusted datamanagement platform, and issue a data verification request 602 to thetrusted assertion service 400 that includes the generated hash. Thetrusted assertion service 600 may return a data verification response604 indicating whether the hash was previously recorded in the trusteddatabase and/or ledger 502.

The data marketplace service 600 and/or the associated trusted datamanagement platform may return to the data consumer system 108 (e.g.,the content publisher) the requested content and/or the associated IDinformation associated with the content author, creator, and/or otherassociated party with rights to the content. The returned response mayfurther comprise timestamp information and/or an indication as towhether the data marketplace service 600 and/or the associated trusteddata management platform successfully verified that the associatedinformation was registered by the trusted assertion service 400 (e.g.,registered via a previously recorded fact information).

It will be appreciated that a number of variations can be made to thearchitecture, relationships, and examples presented in connection withFIGS. 1-6 within the scope of the inventive body of work. For example,certain functionalities of a data provider, a trusted data managementplatform, data processing services, a data marketplace, and/or a trustedassertion service may be performed by and/or otherwise integrated in asingle entity, system, and/or service, and/or any suitable combinationof entities, systems, and/or services. In at least one non-limitingexample, certain functionality provided the data marketplace service anda trusted data management platform may be integrated into a singleservice. Thus, it will be appreciated that the architecture,relationships, and examples presented in connection with FIGS. 1-6 areprovided for purposes of illustration and explanation, and notlimitation.

FIG. 7 illustrates a flow chart of an example of a method 700 forgenerating and/or recording assertion information with a trustedassertion service consistent with various embodiments of the presentdisclosure. The illustrated method 700 and/or aspects thereof may beperformed by and/or in conjunction with software, hardware, firmware,and/or any combination thereof. In various embodiments, the method 700may be performed by a trusted data management platform configured toprocess data and record fact information with a trusted assertionservice.

At 702, a first data set may be accessed and/or received. In someembodiments, the first data set may be provided to the trusted datamanagement platform by a data provider. In further embodiments, thefirst data set may comprise a data set that has been previouslyprocessed by the trusted data management platform and/or another entity(e.g., a data processing service and/or the like).

The first data set may be processed by the trusted data managementplatform using a data processing program to generate a second data setat 704. The first data set may be processed and/or transformed in avariety of ways including using any of the data processing and/ortransformation operations described herein. In some embodiments, thedata processing program may be provided to the trusted data managementplatform by a data processing service.

At 706, fact information associated with the second data set may begenerated. The fact information may comprise a variety of informationassociated with the second data set including, for example and withoutlimitation, one or more of identifying information relating to the dataprocessing program and/or associated service used to generate the seconddata set, a hash of the first data set and/or a portion thereof, a hashof the second data set and/or a portion thereof, timestamp information(e.g., timestamp information associated with the generation of thesecond data set), configuration and/or condition information relating tothe generation of the second data set, and/or description and/or otherinformation detailing changes, transformations, and/or processes wereapplied on the first data set to generate the second data set. Thegenerated fact information may be associated with the second data set bythe trusted data management platform at 708.

At 710, an assertion may be generated by the trusted data managementplatform associated with the generation of the second data set. In someembodiments, the assertion may comprise a hash of the fact informationgenerated at 706 and/or a portion thereof and at least one digitalsignature (e.g., a digital signature over the hash). For example, insome embodiments, the assertion may be signed using a key associatedwith the trusted data management platform. The assertion may in additionand/or alternatively be signed using a key associated with the dataprocessing program used to generate the second data set and/or anassociated data processing service.

Consistent with embodiments disclosed herein, the signed data assertionmay be communicated to a trusted assertion service at 712. The trustedassertion service may authenticate any associated signatures and recordauthenticated assertion information (e.g., included hash information) inan assertion database and/or ledger managed by the trusted assertionservice if the associated signature(s) is/are successfullyauthenticated.

FIG. 8 illustrates a flow chart of an example of a method 800 forverifying information associated with data and/or processed data setsusing a trusted assertion service consistent with various embodiments ofthe present disclosure. The illustrated method 800 and/or aspectsthereof may be performed by and/or in conjunction with software,hardware, firmware, and/or any combination thereof. In variousembodiments, the method 800 may be performed by a trusted assertionservice configured to authenticate and/or verify fact informationassociated with data.

At 802, a data verification request may be received from a data consumersystem by the trusted assertion service requesting verification of factinformation associated with data. Hash information included in the dataverification request may be extracted from the request at 804. Theextracted hash information may be compared with one or more entries inan assertion ledger and/or database managed by the trusted assertionservice to determine whether the extracted hash information has beenpreviously recorded in the assertion ledger and/or database at 806. Ifthe hash information has been recorded in the assertion ledger and/ordatabase, the trusted assertion service may return at 808 a dataverification response to the data consumer system indicating the factinformation was validated by the trusted service. If the hashinformation has not been recorded in the assertion ledger and/ordatabase, however, the trusted assertion service may return at 810 adata verification response indicating the fact information was notvalidated by the trusted service.

Various embodiments of the disclosed systems and methods may be used inconnection with managing electronic content including, for example andwithout limitation, audio, video, written, and/or image content, and/orother related data. Content creators, owners, and/or other partieshaving rights to content may wish to ensure that their rights to theircontent are respected. Moreover, content publishers and/or otherentities, such as a PROs, may wish to ensure that the content theypublish and/or otherwise interact with is authentic and/or that theyrespect the rights of associated rightsholders.

Consistent with certain embodiments of the disclosed systems andmethods, content creators and/or other participants in a contentecosystem may interact with a trusted data management platform and/or atrusted assertion service, among other entities, to manage contentand/or verify the integrity, provenance, and/or chain-of-handling ofcontent and/or associated data. For example, in various embodiments,content creators and/or other parties having rights to content mayregister their content and/or associated rights using a trusted datamanagement platform and/or a trusted assertion service.

FIGS. 9A-9B illustrate an example of a process of registering contentand/or associated rights using a trusted data management platform and/ora trusted assertion service consistent with various embodiments of thepresent disclosure. A variety of entities and/or ecosystem participantsmay engage in various aspects of the illustrated process including, forexample and without limitation, a content creator 900, a contentregistration web front service 904, an ID management provider service(“IDP”) 902, an intelligent identity and access management (“HAM”)service 906, a file server 908, a trusted and/or otherwise secureexecution environment (“SEE”) 910, a trusted ledger and/or database(e.g., a trusted immutable data assertion ledger (“TIDAL”)) 912, and/ora trusted data management platform (which in certain instances hereinand in the figures may be abbreviated as “TP”).

Various functionality of the systems, services, entities, and/orexecution environments illustrated in the figures and described hereinmay be integrated into and/or otherwise performed by single systemsand/or services and/or any suitable combination of multiple systemsand/or services. For example, in some embodiments, the IIAM service 906,file server 908, and/or SEE 910, may be associated with and/or otherwiseimplemented and/or managed by a single TP.

In addition, certain embodiments disclosed herein, including thoseillustrated in FIGS. 9A-9B and elsewhere in the figures, are describedin connection with a content creator that may be a songwriter and/or anassociated entity and content that comprises audio content. It will beappreciated that various aspects of the disclosed embodiments may,however, be used in connection with a variety of types of content (e.g.,audio, video, image, and/or written content, etc.) and/or in connectionwith other types content creators, generators, and/or other partieshaving rights to content. Moreover, although various examples describeactions performed by a content creator, it will be appreciated thatother parties may engage in the same and/or similar interactions thatmay not necessarily be creators of content, but may be contentdistributors, managers, and/or other parties having interest and/orrights to content within a content ecosystem.

Referring to FIG. 9A, a process for registering content and/orassociated information may include:

1.0—A content creator 900 such as, for example and without limitation, asongwriter may issue an access request to a content registration serviceweb front 904.

1.1—The songwriter and/or other content creator 900 may forward to anIDP service 902 and/or otherwise may provide the IDP service 902 withlogin information that may comprise an identifier and/or otherauthentication credentials. For example, a songwriter may provide theIDP service 902 with a songwriter ID (“SWID”) and/or a password.

1.2—If the IDP service 902 determines that the login information isassociated with an authorized user, the IDP service 902 may issue a JSONweb token (“JWT”) to the content registration service web front 904.

1.3—The content registration service web front 904 may forward the JWTto an IIAM service 906, which may be associated with a TP.

1.4—If the JWT is associated with an authenticated user, the IIAMservice 906 may return an access token to the content registrationservice web front 904.

1.5—The songwriter and/or other content creator 900 may communicatecontent they wish to register to the content registration service webfront 904. In some embodiments, the content may comprise a filecorresponding to the content and/or associated metadata information. Forexample, a songwriter may communicate a song file and associatedmetadata to the content registration service web front 904.

2.0—The content registration service web front 904 may forward aregistration request to a trusted content registration program executingwithin a SEE 910 of the TP. The registration request may comprise one ormore of the content file, associated metadata, and/or the SWID and/orother content creator identifier. The request may further include theaccess token issued by the IIAM service 906.

2.1—The access token may be forwarded by the trusted program executingwithin the SEE 910 of the TP to the IIAM service 906 for authentication.

2.2—The IIAM service 906 may return an indication to the trusted programexecuting within the SEE 910 indicating whether the access token wasauthenticated (e.g., OK and/or not good—(“NG”)).

2.3—If the access token was authenticated by the IIAM service 906, thetrusted program executing within the SEE 910 of the TP may retrieveand/or generate timestamp information.

2.4—The trusted program executing within the SEE 910 may generate aunique binding ID associated with the content. In some embodiments, thisbinding ID may be referred to as a binding ID for a particular work(“IDB-W”).

2.5—The trusted program executing within the SEE 910 may create abinding that comprises one or more of the content (e.g., the contentfile), associated metadata, content creator and/or content rightsholderidentification information, content identification information, and/ortimestamp information. For example, a binding may be generated thatincludes an audio content file, associated metadata, the SWID of thecontent creator 900, the generated timestamp information, and the IDB-Wfor the particular work.

2.6—A signed hash of the binding may be created by the trusted programexecuting within the SEE 910. In some embodiments, the signed hash ofthe binding may be signed with a secure key associated with the trustedprogram. The secure key may be protected by the SEE 910 using securehardware and/or using other key protection techniques implemented by theprogram such as, for example and without limitation, whiteboxcryptographic protection techniques.

2.7—The signed hash of the binding may be communicated to a ledgerservice 912, which may be implemented by the TP. In some embodiments,the ledger may comprise a TIDAL, although other suitable types ofledgers and/or databases may also be used. In further embodiments, theledger service 912 may be separate from the TP and be managed by atrusted assertion service.

2.8—The ledger service 912 may determine whether the signed hash of thebinding can be recorded in the ledger in accordance with policyassociated with the ledger and/or database maintained by the ledgerservice 912. For example, the ledger service 912 may determine whetherthe signature associated with the signed hash is associated with anauthorized program and/or entity permitted to record information in theledger and/or database.

2.9—If the entry ingestion policy is satisfied (e.g., the signature isassociated with an authorized program), the ledger service 912 may addthe hash of the binding to the ledger and/or database.

2.10—The ledger service 912 may communicate an indication to the programexecuting within the SEE 910 indicating whether the hash of the bindingwas entered into the ledger and/or database (e.g., OK or NG).

Referring to FIG. 9B, the process for registering content and/orassociated information may further include:

2.11—The program executing with the SEE 910 may communicate a contentinsertion request to a file server 908. In some embodiments, the fileserver 908 may be implemented by and/or otherwise be associated with theTP. In further embodiments, the file server 908 may be a separate fileserver in communication with and/or managed by the TP. The insertionrequest may comprise one or more of the content (e.g., the contentfile), associated metadata, content creator and/or content rightsholderidentification information, content identification information, and/orthe previously received access token. For example, a binding may begenerated that includes an audio content file, associated metadata, theSWID of the content creator 900, the access token received from the IIAMservice 906, and the IDB-W for the particular work. In some embodiments,the content insertion request may further include timestamp information.

2.12—The file server 908 may forward an access token included in thecontent insertion request to the IIAM service 906 for authentication.

2.13—The IIAM service 906 may return an indication to the file server908 indicating whether the access token was authenticated (e.g., OKand/or NG).

2.14—If the IIAM service 906 authenticates the access token, the fileserver 908 may update a database it manages to include the informationincluded in the insertion request, including the content file. Althoughnot specifically illustrated, in some embodiments, the file server 908may return a confirmation to the program executing within the SEE 910that the database has been updated and/or that the content file has beensuccessfully included in the database of the file server 908.

2.15—The program executing within the SEE 910 may return the contentidentification information and timestamp to the content registrationservice web front 904. For example, as illustrated, the IDB-W for theparticular content and the timestamp information may be communicated tothe content registration service web front 904.

3.0—The content registration service web front 904 may return anindication of the content identification information and the timestampinformation to the content creator and/or other rightsholder 900. Forexample, as illustrated, the IBD-W for the content and the timestampinformation may be communicated to a songwriter content creator 900.

4.0—The content creator and/or other rightsholder 900 may provide thecontent identification information to a publisher service 914. Forexample, a songwriter content creator 900 may provide the IDB-W for thecontent to the publisher service 914.

5.0—In various embodiments, the publisher service 914 may be interestedin accessing the content for publication and/or authenticating certainrights and/or other information associated with the content. Thepublisher service 914 may provide authentication information to the IIAMservice 906. For example, in some embodiments, the publisher service 914may communicate ID and/or password information to the IIAM service 906for authentication.

5.1—If the IIAM service 906 authenticates the publisher service 914, itmay return an access token to the publisher service 914.

5.2—The publisher service 914 may provide the received access tokenalong with an indication of selected and/or otherwise requested contentand/or associated information to the program executing within the SEE910 of the TP. For example, as illustrated, the publisher service 914may provide the program executing within the SEE 910 with an indicationof the audio content, metadata, the SWID, and/or the IDB-W associatedwith the selected/requested content.

5.3—The program executing within the SEE 910 may communicate the accesstoken along with the indication of the selected and/or otherwiserequested content to the file server 908. Although not specificallyillustrated, the program executing within the SEE 910 may alsoauthenticate the access token of the publisher with the IIAM service906.

5.4—The file server 908 may forward the publisher access token to theIIAM service 906 for authentication.

5.5—The IIAM service 906 may return an indication to the file server 908indicating whether the publisher access token was authenticated (e.g.,OK and/or NG).

5.6—If the publisher access token was authenticated, the file server 908may return the content, associated data, content creator identificationinformation, and/or timestamp information to the program executingwithin the SEE 910. For example, the file server 908 may return audiocontent, associated metadata, a SWID, and timestamp information to theprogram executing within the SEE 910.

5.7—The program executing within SEE 910 may generate a hash of abinding that comprises one or more of the content, associated metadata,content creator identification information, timestamp information,and/or content identification information. For example, as illustrated,a binding of the audio content, associated metadata, the SWID, thetimestamp information, and the IDB-W may be generated.

5.8—The generated hash of the binding may be communicated to the ledgerservice 912 by the program executing within the SEE 910 forverification. In some embodiments, this may be as part of query todetermine whether the ledger and/or database maintained by the ledgerservice 912 includes the hash of the binding.

5.9—The ledger service 912 may return to the program executing withinthe SEE 910 an indication regarding whether the hash has been recordedin the ledger and/or database maintained by the ledger service 912(e.g., “true”, whether the hash has not been recorded in the ledgerand/or database (e.g., “false”), and/or whether there is some indicationof tampering (e.g., “unknown”). In various embodiments, the returnedindication may provide an indication as to the integrity and/orauthenticity of the content and/or associated information.

5.10—If the ledger service 912 returns an indication indicating that thecontent is authenticated and/or valid, the content may be provided tothe publisher service 914 along with associated information. Forexample, the program executing within the SEE 910 may provide thepublisher with the audio content file, associated metadata, an SWID,timestamp information, and/or an IDB-W.

Content publishers and/or other entities participating in a contentecosystem, such as a PRO, may be interested in ensuring that the contentthey publish and/or otherwise interact with is authentic and that theyrespect the rights of content generators, owners, and/or other partieshaving interests in the content. For example, in some embodiments, a PROmay interact with a trusted data management platform to identify whethercertain assertions associated with content have been recorded by atrusted ledger and/or ascertain information relating to rightsassociated with the content.

FIGS. 10A-10B illustrate an example of a process for verifying rightsassociated with content involving a PRO consistent with variousembodiments of the present disclosure. Referring to FIG. 10A, whichillustrates a first part a process for verifying rights associated withcontent by a PRO service 1000, the process may include:

6.0—A publisher service 914 may communicate content identificationinformation to a PRO service 1000. For example, the publisher service914 may communicate an IDB-W associated with a particular audio contentwork to a PRO service 1000.

7.0—The PRO service 1000 may provide authentication information to theIIAM service 906 for authentication. For example, in variousembodiments, the PRO service 1000 may provide ID and/or associatedpassword information to the IIAM service 906 for authentication.

7.1—If the IIAM service 906 authenticates the PRO service 1000, it mayreturn an access token to the PRO service 1000.

7.2—The PRO service 1000 may provide the received access token alongwith an indication of selected and/or otherwise requested content to theprogram executing within the SEE 910 of the TP. For example, in someembodiments, the indication may comprise an indication of the audiocontent, metadata, the SWID, and/or the IDB-W associated with theselected/requested content.

7.3—The program executing within the SEE 910 may communicate the accesstoken associated with the PRO service 1000 along with the indication ofthe selected and/or otherwise requested content to the file server 908.Although not specifically illustrated, the program within the SEE 910may also authenticate the access token of the PRO service 1000 with theIIAM service 906.

7.4—The file server 910 may return the content file, associatedinformation, content creator and/or rightsholder identificationinformation, and/or timestamp information to the program executingwithin the SEE 910. For example, as illustrated, the file server 908 mayreturn a requested audio content file, associated metadata, an SWIDassociated with the audio content file, and/or timestamp information tothe program executing within the SEE 910.

7.5—The program executing within the SEE 910 may generate a hash of abinding that comprises one or more of the content file, associatedmetadata, content creator and/or rightsholder identificationinformation, timestamp information, and/or content identificationinformation. For example, in some embodiments, a hash may be generatedof a binding that comprises the audio content, associated metadata, aSWID, the timestamp information, and the IDB-W associated with thecontent.

7.6—The hash of the binding may be communicated to the ledger service912 for verification.

7.7—The ledger service 912 may return to the program executing withinthe SEE 910 an indication as to whether the hash is included in theledger and/or database maintained by the ledger service 912 (e.g.,true), whether the hash is not included in the ledger and/or database(e.g., false), and/or whether there is some indication of tampering(e.g., unknown). This indication may provide an indication as to theintegrity and/or authenticity of the content and/or associatedinformation.

7.8—If the ledger service 912 returns an indication that the content isauthenticated and/or valid, the content file may be provided to the PROservice 1000, potentially along with other associated information. Forexample, in some embodiments, audio content may be returned to the PROservice 1000 by the trusted program executing within the SEE 910 alongwith associated metadata, SWID associated with the songwriter and/orother rightsholder, timestamp information, and/or the IDB-W associatedwith the content.

8.0—The PRO service 1000 may communicate to the publisher 914 anassigned identifier and/or reference ID associated with the content. Forexample, as illustrated, the PRO service 1000 may communicate anInternational Standard Musical Work Code (“ISWC”) to the publisherservice 914. In various embodiments, the ISWC may comprise a unique,permanent, and/otherwise recognized (e.g., internationally recognized)reference number for the identification of musical works and/or content.

In some embodiments, the publisher service 914 may wish to register theassigned identifier and/or reference ID associated with the content withthe ledger service 912. Referring to FIG. 10B, the process for verifyingrights associated with content may further include:

9.0—The publisher service 914 may provide authentication information(e.g., ID information and/or password information) to the IIAM service906 for authentication.

9.1—If the IIAM service 906 authenticates the publisher service 914, itmay return an access token to the publisher service 914.

9.2—The publisher service 914 may wish to add the assigned identifierand/or reference ID associated with the content to the trusted ledgerand/or database maintained by the ledger service 912. For example, insome embodiments, the publisher service 914 may wish to add the ISWC tothe ledger and/or database maintained by the ledger service 912. In someembodiments, the publisher service 914 may further wish to add theassigned identifier and/or reference ID associated with the content(e.g., the ISWC) to the ledger and/or database maintained by the fileserver 908. In some embodiments, the publisher service 914 may providethe trusted program executing within the SEE 910 with an add requestthat comprises associated identifier information. For example, asillustrated, the add request may comprise an ISWC and/or IDB-Wassociated with audio content. The add request may further includeand/or be communicated with the publisher access token.

9.3—The program executing within the SEE 910 may forward the publisheraccess token to the IIAM service 906 for authentication.

9.4—The IIAM service 906 may return an indication to the programexecuting within the SEE 910 indicating whether the publisher accesstoken was successfully authenticated (e.g., OK and/or NG).

9.5—The program executing within the SEE 910 may communicate thepublisher access token along with the add request to the file server908. For example, as illustrated, the program executing within the SEE910 may communicate the publisher access token along with an add requestcomprising the ISWC and associated IDB-W to the file sever 908.

9.6—The file server 908 may forward the publisher access token to theIIAM service 906 for authentication.

9.7—The IIAM service 906 may return an indication to the file server 908indicating whether the publisher access token was authenticated (e.g.,OK and/or NG).

9.8—If the publisher access token was authenticated, the file server 908may return the content file, associated metadata, content creator and/orrightsholder identification information, and/or timestamp information tothe program executing within the SEE 910. For example, as illustrated,the file server 908 may return the audio content file and associatedmetadata, SWID, and timestamp information the program executing withinthe SEE 910.

9.9—The program executing within the SEE 910 may create a binding thatcomprises one or more of the content file, associated metadata, contentcreator and/or rights holder identification information, timestampinformation, and/or one or more content identifiers. In at least onenon-limiting example, the binding may comprise an audio content file,associated metadata information, SWID, timestamp information, acorresponding IDB-W associated with the audio content, and/or acorresponding ISWC associated with the audio content.

9.10—A signed hash of the binding may be generated. In some embodiments,the signed hash of the binding may be signed with a secure keyassociated with the program executing with the SEE 910. The secure keymay be protected by the SEE 910 using secure hardware and/or using otherkey protection techniques implemented by the trusted program such as,for example and without limitation, whitebox cryptographic protectiontechniques.

9.11—The signed hash of the binding may be communicated to a ledgerservice 912 maintaining a trusted ledger and/or database. In someembodiments, the ledger may comprise a TIDAL, although other suitabletypes of trusted ledgers and/or databases may also be employed. Asdescribed above, the ledger service 912 may be implemented by the TPand/or by a separate trusted service such as, for example and withoutlimitation, a trusted assertion service.

9.12—The ledger service 912 may determine whether the signed hash of thebinding can be recorded in accordance with policy associated with theledger and/or database maintained by the ledger service 912. Forexample, the ledger service 912 may determine whether the signatureassociated with the signed hash is associated with an authorized programand/or entity permitted to record information in the ledger and/ordatabase.

9.13—If the entry ingestion policy is satisfied (e.g., the signature isassociated with an authorized program), the ledger service 912 may addthe hash of the binding to the ledger and/or database.

9.14—The ledger service 912 may communicate an indication to the programexecuting within the SEE 910 whether the hash of the binding was enteredinto the ledger and/or database.

9.15—In turn the program executing with the SEE 910 may return anindication to the publisher service 914 indicating whether the hash ofthe binding was entered into the ledger and/or database and/or the ISWCwas otherwise recorded.

In various further embodiments, a DRM service may interact with atrusted data management platform and/or a trusted assertion service toverify and/or otherwise manage rights associated with content. Forexample, in some embodiments, content files may be protected using a DRMservice that operates in connection with a TP and/or trusted assertionservice maintaining a trusted ledger and/or database to manage licensesand/or rights associated with content. In various embodiments, a TPand/or an associated SEE may handle content key related transactions ina manner such that a content key is not exposed outside a protectedenvironment of the TP and/or an associated SEE.

FIG. 11A-11B illustrate an example of a content management processinvolving a DRM service consistent with various embodiments of thepresent disclosure. A variety of entities and/or ecosystem participantsmay engage in various aspects of the illustrated process including, forexample and without limitation, a content creator and/or otherrightsholder 900, a content registration web front service 904, an IDPservice 902, an IIAM service 906, file servers 908 and 1100, a DRMservice 1102, an SEE 910, a trusted ledger and/or database service 912,and/or a TP.

As discussed above, various functionality of the systems, services,entities, and/or execution environments illustrated in the figures anddescribed herein may be integrated into and/or otherwise performed bysingle systems and/or services and/or any suitable combination ofmultiple systems and/or services. For example, in some embodiments, oneor more of the IIAM service 906, one or more of file servers 908 and1100, and/or the SEE 910 may be associated with and/or otherwiseimplemented and/or managed by a single TP. Moreover, it will beappreciated that in some embodiments, functionality of file servers 908and 1100 may be integrated into a single file server.

Referring to FIG. 11A, a process for registering content and/orassociated information may include:

1.0—A content creator and/or other rightsholder 900 such as, for exampleand without limitation, a songwriter may issue an access request to acontent registration service web front 904.

1.01—The songwriter and/or other content creator 900 may forward to anIDP service 902 and/or otherwise may provide the IDP service 902 withlogin information that may comprise an identifier and/or otherauthentication credentials. For example, a songwriter may provide theIDP service 902 with an SWID and/or a password.

1.02—If the IDP service 902 determines that the login information isassociated with an authorized user, the IDP service 902 may issue a JWTto the content registration service web front 904.

1.03—The content registration service web front 904 may forward the JWTto an IIAM service 906, which may be associated with a TP.

1.04—If the JWT is associated with an authenticated user, the IIAMservice 906 may return an access token to the content registrationservice web front 904.

1.1—The content creator and/or other rightsholder 900 may communicatecontent they wish to register to the content registration service webfront 904. In some embodiments, the content may comprise a filecorresponding to the content and/or associated metadata information. Forexample, a songwriter may communicate a song file and associatedmetadata to the content registration service web front 904.

1.2—The content registration service web front 904 may forward aregistration request to a trusted content registration program executingwithin a SEE 910 of the TP. The registration request may comprise one ormore of the content file, associated metadata, and/or the SWID and/orother content creator identifier. The request may further include theaccess token issued by the IIAM service 906.

1.2.1—The access token may be forwarded by the trusted program executingwithin the SEE 910 of the TP to the IIAM service 906 for authentication.

1.2.2—The IIAM service 906 may return an indication to the trustedprogram executing within the SEE 910 indicating whether the access tokenwas authenticated (e.g., OK and/or not good—(“NG”)).

1.2.2.1—If the access token was authenticated by the IIAM service 906,the trusted program executing within the SEE 910 of the TP may generatean International Standard Content Code (“ISCC”) and/or anotheridentifier (and/or may interact with another service to generate such anidentifier) associated with the content and/or title informationassociated with the content.

1.2.3—The program executing within the SEE 910 of the TP may retrieveand/or generate timestamp information.

1.2.4—The trusted program executing within the SEE 910 may generate aunique binding ID associated with the content (e.g., an IDB-W).

1.2.5—The trusted program executing within the SEE 910 may create abinding that comprises one or more of the ISCC, a hash of the associatedcontent metadata, the SWID and/or other content creator identifier, thetimestamp information, and the IDB-W for the particular work.

1.2.6—A signed hash of the binding may be created by the trusted programexecuting within the SEE 910. In some embodiments, the signed hash ofthe binding may be signed with a secure key associated with the trustedprogram and/or the SEE 910. The secure key may be protected by the SEE910 using secure hardware and/or using other key protection techniquesimplemented by the program such as, for example and without limitation,whitebox cryptographic protection techniques.

Referring to FIG. 11B, the process for registering content and/orassociated information may further include:

1.2.7—The signed hash of the binding may be communicated to a ledgerservice 912, which may be implemented by the TP. In some embodiments,the ledger may comprise a TIDAL, although other suitable types ofledgers and/or databases may also be used. In further embodiments, theledger service 912 may be separate from the TP and be managed by atrusted assertion service.

1.2.8—The ledger service 912 may determine whether the signed hash ofthe binding can be recorded in the ledger in accordance with policyassociated with the ledger and/or database maintained by the ledgerservice 912. For example, the ledger service 912 may determine whetherthe signature associated with the signed hash is associated with anauthorized program and/or entity permitted to record information in theledger and/or database.

1.2.9—If the entry ingestion policy is satisfied (e.g., the signature isassociated with an authorized program), the ledger service 912 may addthe hash of the binding to the ledger and/or database.

1.2.10—The ledger service 912 may communicate an indication to theprogram executing within the SEE 910 indicating whether the hash of thebinding was entered into the ledger and/or database (e.g., OK or NG).

1.2.10.1—The trusted program executing within the SEE 910 may generate acontent key and an associated content key identifier.

1.2.10.2—The trusted program executing within the SEE 910 may encryptthe content file with the generated content key.

1.2.10.3—The trusted program executing within the SEE 910 may encryptthe content key with a key associated with the SEE 910. In someembodiments, the key associated with the SEE 910 may be protected byand/or otherwise not exposed outside the SEE 910 (e.g., using securehardware protection techniques and/or software-based cryptographicprotection techniques). The key associated with the SEE 910 may comprisean asymmetric key or a symmetric key.

1.2.10.4—The encrypted content may be communicated to and/or stored by afile server 1100 (that in some embodiments may be associated with the TPand/or the SEE 910).

1.2.10.5—A location (e.g., a URL) of the encrypted audio content (and/orthe encrypted content key) may be returned from the file server 1100 tothe trusted program executing with the SEE 910.

1.2.11—The program executing with the SEE 910 may communicate aninsertion request to a file server 908. In some embodiments, the fileserver 908 may be the same file server as file server 1100. In furtherembodiments, the file server 908 may be a separate file server from fileserver 1100. The file server 908 may in some embodiments be associatedwith the TP and/or may be a separate data server in communication withand/or managed by the TP. The insertion request may comprise one or moreof the ISCC, the location of the encrypted content file (e.g., thelocation of the encrypted content file in file server 1100), theencrypted content key and/or associated ID information, metadata,content creator information such as an SWID, timestamp information,and/or an IDB-W for the particular work. The access token issued to thetrusted program executing within the SEE 910 may be further included inand/or communicated with the insertion request.

1.2.12—The file server 908 may forward the access token to the IIAMservice 906 for authentication.

1.2.13—The IIAM service 906 may return an indication to the file server908 indicating whether the access token was authenticated (e.g., OKand/or NG).

1.2.14—If the IIAM service 906 authenticates the access token, the dataserver may update the database with the information included in theinsertion request. Although not specifically illustrated, in someembodiments, the data server may return a confirmation to the programexecuting within the SEE 910 that the database has been updated.

1.2.15—The program executing within the SEE 910 may return the IDB-W,the timestamp information, and the ISCC to the content registrationservice web front 904.

1.3—The content registration service web front 904 may return anindication of the IBD-W, the timestamp information, and the ISCC to thecontent creator and/or other rightsholder 900.

In various embodiments, content key and/or license management processesmay be implemented using a DRM service 1102. For example, when anauthorized publisher requests to render (e.g., stream) content, thetrusted program executing within the SEE 910 of the TP may handlecertain content key transactions by interacting with a DRM service 1102.FIGS. 12A-12B illustrate an example of a process for managingcryptographic keys associated with content consistent with variousembodiments of the present disclosure. Referring to FIG. 12A, whichillustrates a first part of a key management process, the process mayinclude:

2.0—The content creator and/or other rightsholder 900 (e.g., asongwriter) may communicate content identification information to thepublisher service 914. For example, the content creator 900 maycommunicate an IDB-W associated with a particular work to the publisherservice 914.

3.0—The publisher service 914 may be interested in accessing the contentfor publication and/or authenticating certain rights and/or otherinformation associated with the content. The publisher service 914 mayprovide its authentication information (e.g., ID information and/orpassword information) to the IIAM service 906 for authentication.

3.0.1—If the IIAM service 906 authenticates the publisher service 914,it may return an access token to the publisher service 914.

3.1—The publisher service 914 may provide the received access tokenalong with an indication of selected and/or otherwise requested contentto the program executing within the SEE 910 of the TP. In someembodiments, the indication may comprise an indication of a piece ofrequested audio content, metadata, the SWID, and/or the IDB-W associatedwith the selected/requested content.

3.2.1—The program executing within the SEE 910 may communicate theaccess token along with the indication of the selected and/or otherwiserequested content to the file server 908. Although not specificallyillustrated, the program within the SEE may also authenticate the accesstoken of the publisher with the IIAM service 906.

3.2.2—The file server 908 may forward the publisher access token to theIIAM service for authentication.

3.2.3—The IIAM service 906 may return an indication to the file server908 indicating whether the publisher access token was authenticated(e.g., OK and/or NG).

3.2.4—If the publisher access token was authenticated, the file server908 may return the ISCC, a location of the content (e.g., the file URL),the associated encrypted content key and/or an associated content keyID, metadata, content creator and/or rightsholder identifier (e.g.,SWID), and/or timestamp information to the trusted program executingwithin the SEE 910.

3.2.5—The program executing within the SEE 910 may generate a hash of abinding that comprises one or more of the ISCC, a hash of the associatedcontent metadata, the SWID and/or other content creator and/orrightsholder identifier, the timestamp information, and the IDB-W forthe particular work.

3.2.6—The hash of the binding may be communicated to the ledger service912 for verification.

3.2.7—The ledger service 912 may return to the program executing withinthe SEE 910 an indication as to whether the hash is included in theledger and/or database maintained by the ledger service (e.g., “true”),whether the hash is not included in the ledger and/or database (e.g.,“false”), and/or whether there is some indication of tampering (e.g.,“unknown”).

3.2.8—The encrypted content key may be loaded (e.g., loaded from adatabase) by the trusted program executing within the SEE 910. Theencrypted content key may be decrypted with the key associated with theSEE 910 and/or the trusted program.

Referring to FIG. 12B, the key management process may further include:

3.2.9—The trusted program executing within the SEE 910 may communicatethe content key and associated content key ID to the DRM service 1102 toretrieve an associated token.

3.2.10—In response, the DRM service 1102 may communicate the DRM tokento the program executing within the SEE 910.

3.3—The DRM token retrieved from the DRM service 1102 may becommunicated to the publisher service 914 along with a location of theencrypted content file (e.g., file URL), associated metadata, contentcreator and/or rightsholder identification information (e.g., an SWID),the timestamp, the IDB-W, and/or the ISCC to the publisher service 914.

3.4—The publisher service 914 may feed the retrieved DRM token to a DRMclient of a client application executed by the publisher service 914(e.g., Widevine in a Chrome browser) to initiate a DRM licenseacquisition process with the DRM service 1102.

3.5—The DRM client of the publisher service 914 may communicate theretrieved DRM token to the DRM service 1102.

3.6—If the DRM service 1102 verifies the received DRM token, it mayissue a DRM license to the publisher service 914 (e.g., to the DRMclient of the publisher service 914). In some embodiments, the DRMlicense may comprise the content key.

3.7—The publisher service 914 may communicate a request for the contentto the file server 1100. The request may include the location of theencrypted content (e.g., file URL).

3.8—The encrypted content may be returned to the publisher service 914from the file server 1100.

3.9—The encrypted content may be decrypted using the content keyincluded in the DRM license (possibly after complying with any other DRMlicense terms that may be enforced). Once decrypted, the audio contentmay be rendered and/or otherwise played back by the publisher service914.

It will be appreciated that a number of variations can be made to thearchitecture, relationships, and examples presented in connection withFIGS. 9A-12B within the scope of the inventive body of work. Forexample, certain functionalities of a content creator and/or otherrightsholder 900, content registration web front service 904, IDPservice 902, IIAM service 906, file servers 908 and 1100, DRM service1102, SEE 910, ledger service 912 which may be associated with a TPand/or a trusted assertion service, publisher service 914, and a PRO1000 may be performed by and/or otherwise integrated in a single entity,system, and/or service, and/or any suitable combination of entities,systems, and/or services. Thus, it will be appreciated that thearchitecture, relationships, and examples presented in connection withFIGS. 9A-12B are provided for purposes of illustration and explanation,and not limitation.

Moreover, although various embodiments and/or examples are describedherein in connection with applications and/or contexts involvinginteractions between a PRO, a trusted data management platform, atrusted assertion service, and/or a DRM service, it will be appreciatedthat certain disclosed embodiments may be implemented in a variety ofother applications, contexts, and/or use cases. For example and withoutlimitation, courts and/or other legal entities may seek to verify and/orascertain certain legal and/or evidentiary facts. Parties associatedwith legal and/or evidentiary facts may register associated factinformation with a trusted data management platform and/or a trustedassertion service. Parties wishing to securely access and/or validatesuch facts may interact with the trusted data management platform toidentify whether associated fact information have been recorded by atrusted ledger and/or ascertain information relating to rightsassociated with the content. In some embodiments, a DRM service may beused to ensure that access to facts and/or associated information isprovided to authorized parties (e.g., as may be used in connection withenforcing legal protective and/or confidential orders limiting access toconfidential documents and/or the like).

In another non-limiting example, content may be associated with metadatathat may specify various rights, royalty, and/or other paymentinformation. Such metadata may be registered with a trusted datamanagement platform and later verified to determine, among other things,what required royalties for publishing content are, to what entityand/or entities such royalties should be paid, how such royalties shouldbe paid, and/or the like. In some embodiments, this may enable contentpublishers to determine how to directly compensate content providers forpublication rights.

FIG. 13 illustrates a flow chart of an example of a method 1300 formanaging electronic content by a trusted data management platformconsistent with various embodiments of the present disclosure. Theillustrated method 1300 and/or aspects thereof may be performed byand/or in conjunction with software, hardware, firmware, and/or anycombination thereof. In various embodiments, the method 1300 may beperformed by a trusted data management platform configured to manageaccess to and/or use of electronic content, which may comprise audiocontent, video content, text content, image content, and/or any othertype of electronic content.

At 1302 a request may be received a trusted program executing in asecure environment of the trusted data management platform from a systemwishing to access the electronic content. In some embodiments, therequest may comprise an identity access token issued to the requestingsystem and first electronic content identification informationassociated with the electronic content the system wishes to access. Theidentity access token may be configured to be validated by a systemusing an IIAM service. In certain embodiments, the requesting system maycomprise a publishing service system, although it will be appreciatedthat systems associated with other services and/or users may issuecontent access requests and participate in various aspects of thecontent management processes described herein.

The trusted program may send a query to a first file server system at1304. In some embodiments, the query may comprise the received identityaccess token and the first electronic content identificationinformation. In certain embodiments, the first file server system may beassociated with and/or otherwise be implemented by the trusted digitalmanagement platform.

At 1306, the trusted program may receive from the first file serversystem a request comprising second electronic content identificationinformation, electronic content file location information, an encryptedcontent key, content rightsholder identification information, andtimestamp information. In further embodiments, the query may furthercomprise content key identification information and/or metadatainformation associated with the electronic content.

In certain embodiments, the electronic content file location informationmay comprise location information of a file corresponding to theelectronic content within a file server system. The file system maycomprise a second file server system which may be implemented by thesame file server system as the first file server system or beimplemented by a separate system.

In some embodiments, the first electronic content identificationinformation and the second electronic content identification informationmay comprise the same electronic content identification information. Infurther embodiments, the second electronic content identificationinformation may comprise an ISCC associated with the electronic content.

The trusted program may generate a binding comprising one or more of thefirst and/or second electronic content identification information, thecontent rightsholder identification information, the timestampinformation, and/or a hash of the metadata information associated withthe electronic content. A cryptographic hash of the generated bindingmay be generated by the trusted program at 1308.

At 1310, the trusted program may query a ledger service with the hashbinding to determine whether a trusted ledger (e.g., a trusted databaseand/or a TIDAL) maintained by the ledger service includes the hashbinding. The ledger service may be associated with the trusted datamanagement platform and/or a trusted assertion service separate from thetrusted data management platform. If the hash is included in the ledger,the trusted program may proceed to decrypt the encrypted content keywith a private key associated with the trusted program and/or the secureexecution environment of the trusted data management platform.

The trusted program may send the decrypted content key and/or associatedcontent key identification information to a DRM service at 1312. At1314, the DRM service may receive a DRM token from the DRM service. Thetrusted program may then send to the system wishing to access theelectronic content one or more of the DRM token, electronic filelocation information, metadata information, timestamp information,contents rightsholder information, and/or first and/or secondidentification information for use in accessing the electronic contentat 1316.

FIG. 14 illustrates an example of a system 1400 that may be used toimplement certain embodiments of the systems and methods of the presentdisclosure. The system 1400 of FIG. 14 and/or components illustrated inconnection with the same may comprise and/or be included a system and/orservice associated with a data provider, a trusted data managementplatform, a data processing service, a trusted assertion service, a DRMservice, a data marketplace service, a data consumer system, apublishing service, and/or any other system, service, and/or deviceconfigured to implement embodiments of the disclosed systems andmethods.

Various systems and/or services associated with embodiments of thedisclosed systems and/or methods may be communicatively coupled using avariety of networks and/or network connections. In certain embodiments,the network may comprise a variety of network communication devicesand/or channels and may utilize any suitable communications protocolsand/or standards facilitating communication between the systems and/ordevices. The network may comprise the Internet, a local area network, avirtual private network, and/or any other communication networkutilizing one or more electronic communication technologies and/orstandards (e.g., Ethernet or the like). In some embodiments, the networkmay comprise a wireless carrier system such as a personal communicationssystem (“PCS”), and/or any other suitable communication systemincorporating any suitable communication standards and/or protocols. Infurther embodiments, the network may comprise an analog mobilecommunications network and/or a digital mobile communications networkutilizing, for example, code division multiple access (“CDMA”), GlobalSystem for Mobile Communications or Groupe Special Mobile (“GSM”),frequency division multiple access (“FDMA”), and/or time divisionalmultiple access (“TDMA”) standards. In certain embodiments, the networkmay incorporate one or more satellite communication links, broadcastcommunication links, and/or the like. In yet further embodiments, thenetwork may utilize IEEE's 802.11 standards, Bluetooth®, ultra-wide band(“UWB”), Zigbee®, and or any other suitable standard or standards.

Various systems and/or devices associated with the disclosed embodimentsmay comprise a variety of computing devices and/or systems, includingany computing system or systems suitable to implement the systems andmethods disclosed herein. For example, the connected devices and/orsystems may comprise a variety of computing devices and systems,including laptop computer systems, desktop computer systems, servercomputer systems, distributed computer systems, smartphones, tabletcomputers, and/or the like.

In certain embodiments, the systems and/or devices may comprise at leastone processor system configured to execute instructions stored on anassociated non-transitory computer-readable storage medium. As discussedin more detail below, the client device and/or one or more other systemsand/or services may further comprise a secure processing unit (“SPU”)configured to perform sensitive operations such as trusted credentialand/or key management, cryptographic operations, secure policymanagement, and/or other aspects of the systems and methods disclosedherein. The systems and/or devices may further comprise software and/orhardware configured to enable electronic communication of informationbetween the devices and/or systems via a network using any suitablecommunication technology and/or standard.

As illustrated in FIG. 14 , a system 1400 may include: a processing unit1402; system memory 1404, which may include high speed random accessmemory (“RAM”), non-volatile memory (“ROM”), and/or one or more bulknon-volatile non-transitory computer-readable storage mediums (e.g., ahard disk, flash memory, etc.) for storing programs and other data foruse and execution by the processing unit; a port 1406 for interfacingwith removable memory 1408 that may include one or more diskettes,optical storage mediums (e.g., flash memory, thumb drives, USB dongles,compact discs, DVDs, etc.) and/or other non-transitory computer-readablestorage mediums; a network interface 1410 for communicating with othersystems via one or more network connections 1412 using one or morecommunication technologies, including any of the network connectionsand/or communication technologies and/or standards described herein; auser interface 1414 that may include a display and/or one or moreinput/output devices such as, for example, a touchscreen, a keyboard, amouse, a track pad, and the like; and one or more busses 1416 forcommunicatively coupling the elements of the system.

In some embodiments, the system may, alternatively or in addition,include an SEE 1418 and/or a trusted execution environment that isprotected from tampering by a user of the system or other entities byutilizing secure physical and/or virtual security techniques. An SEE1418 and/or a TEE can help enhance the security of sensitive operationssuch as personal information management, trusted credential and/or keymanagement, privacy and policy management, license management and/orenforcement, and other aspects of the systems and methods disclosedherein. In certain embodiments, the SEE 1418 and/or TEE may operate in alogically secure processing domain and be configured to protect andoperate on secret information, as described herein. In some embodiments,the SPU 1418 and/or TEE may include internal memory storing executableinstructions or programs configured to enable the SEE 1418 and/or TEE toperform secure operations, as described herein.

The operation of the system may be generally controlled by a processingunit 1402 and/or an SEE 1418 and/or TEE operating by executing softwareinstructions and programs stored in the system memory 1404 (and/or othercomputer-readable media, such as removable memory 1408). The systemmemory 1404 may store a variety of executable programs or modules forcontrolling the operation of the system 1400. For example, the systemmemory 1404 may include an operating system (“OS”) 1412 that may manageand coordinate, at least in part, system hardware resources and providefor common services for execution of various applications and a trustand privacy management system for implementing trust and privacymanagement functionality including protection and/or management ofpersonal data through management and/or enforcement of associatedpolicies. The system memory may further include, without limitation,communication software 1422 configured to enable in part communicationwith and by the system, one or more applications 1424, cryptographicmodules 1426 configured to perform various cryptographic operationsconsistent with the disclosed embodiments, trusted program modules 1428configured to perform various aspects of a trusted program consistentwith the disclosed embodiments, and/or any other information, modules,and/or applications configured to implement embodiments of the systemsand methods disclosed herein.

The systems and methods disclosed herein are not inherently related toany particular computer, electronic control unit, or other apparatus andmay be implemented by a suitable combination of hardware, software,and/or firmware. Software implementations may include one or morecomputer programs comprising executable code/instructions that, whenexecuted by a processor, may cause the processor to perform a methoddefined at least in part by the executable instructions. The computerprogram can be written in any form of programming language, includingcompiled or interpreted languages, and can be deployed in any form,including as a standalone program or as a module, component, subroutine,or other unit suitable for use in a computing environment. Further, acomputer program can be deployed to be executed on one computer or onmultiple computers at one site or distributed across multiple sites andinterconnected by a communication network.

Software embodiments may be implemented as a computer program productthat comprises a non-transitory storage medium configured to storecomputer programs and instructions, that when executed by a processor,are configured to cause the processor to perform a method according tothe instructions. In certain embodiments, the non-transitory storagemedium may take any form capable of storing processor-readableinstructions on a non-transitory storage medium. A non-transitorystorage medium may be embodied by a compact disk, digital-video disk, amagnetic tape, a magnetic disk, flash memory, integrated circuits, orany other non-transitory digital processing apparatus memory device.

Although the foregoing has been described in some detail for purposes ofclarity, it will be apparent that certain changes and modifications maybe made without departing from the principles thereof. For example, itwill be appreciated that a number of variations can be made to thevarious embodiments, devices, services, and/or components presented inconnection with the figures and/or associated description within thescope of the inventive body of work, and that the examples presented inthe figures are provided for purposes of illustration and explanation,and not limitation. It is further noted that there are many alternativeways of implementing both the systems and methods described herein.Accordingly, the present embodiments are to be considered asillustrative and not restrictive, and the embodiments of the inventionare not to be limited to the details given herein, but may be modifiedwithin the scope and equivalents of the appended claims.

What is claimed is:
 1. A method for securely registering electroniccontent performed by a trusted data management platform comprising aprocessor and a non-transitory computer-readable medium storinginstructions that, when executed by the processor, cause the trusteddata management platform to perform the method, the method comprising:receiving, by the trusted data management platform from a systemrequesting to register electronic content with the trusted datamanagement platform, an access request; authenticating an identityaccess token associated with the access request with an identity andaccess management service; receiving, from the system requesting toregister electronic content with the trusted data management platform,an electronic content file, metadata associated with the electroniccontent file, and an identifier associated with a rightsholder of theelectronic content file; issuing a content registration request to atrusted program executing in a secure execution environment of thetrusted data management platform, the content registration requestcomprising the electronic content file and the metadata associated withthe electronic content file; generating, by the trusted program, abinding, the binding comprising the electronic content file, themetadata associated with the electronic content file, the identifierassociated with the rightsholder of the electronic content file, and atimestamp; generating, by the trusted program, a signed hash of thebinding using, at least in part, a secure cryptographic key associatedwith the trusted program; and registering, by the trusted program, thesigned hash of the binding with a trusted ledger maintained by a ledgerservice.
 2. The method of claim 1, wherein the binding further comprisesa binding identifier generated by the trusted program.
 3. The method ofclaim 1, wherein the identifier associated with the rightsholder of theelectronic content file comprises a songwriter identifier.
 4. The methodof claim 1, wherein the rightsholder of the electronic content filecomprises a creator of the electronic content file.
 5. The method ofclaim 1, wherein the secure execution environment of the trusted datamanagement platform is protected using at least one of secure hardwareand secure software.
 6. The method of claim 1, wherein the secureexecution environment of the trusted data management platform isprotected using whitebox cryptographic protection.
 7. The method ofclaim 1, wherein the identity access token comprises a token issued bythe identity and access management service in response to a successfulauthentication of a web token.
 8. The method of claim 7, wherein the webtoken comprises a token issued by an identity management providerservice in response to a successful authentication of credentialsprovided by the system requesting to register electronic content withthe trusted data management platform.
 9. The method of claim 1, whereinthe identity and access management service is a service of the trusteddata management platform.
 10. The method of claim 1, wherein the contentregistration request further comprises the identity access token. 11.The method of claim 10, wherein authenticating the identity access tokenwith an identity and access management service comprises: issuing, bythe trusted program, an authentication request to the identity andaccess management service, the authentication request comprising theidentity access token; and receiving, by the trusted program, anauthentication response from the identity and access management service,the authentication response comprising an indication that the identityaccess token was successfully authenticated by the identity and accessmanagement service.
 12. The method of claim 1, wherein the methodfurther comprises receiving, by the trusted program from the ledgerservice, an indication that the signed hash of the binding wassuccessfully entered into the trusted ledger.
 13. The method of claim 1,wherein the method further comprises issuing, by the trusted program, acontent insertion request to a file server service, the contentinsertion request comprising the electronic content file, the metadataassociated with the electronic content file, and the identifierassociated with the rightsholder of the electronic content file.
 14. Themethod of claim 13, wherein the content insertion request furthercomprises one or more of the identity access token and the timestampinformation.
 15. The method of claim 13, wherein the file server serviceis a service of the trusted data management platform.
 16. The method ofclaim 13, wherein the binding further comprises a binding identifiergenerated by the trusted program, and wherein the content insertionrequest further comprises the binding identifier.
 17. The method ofclaim 13, wherein the method further comprises sending, to the systemrequesting to register electronic content with the trusted datamanagement platform, an indication confirming that the electroniccontent file was registered with the trusted data management platform.18. The method of claim 17, wherein the method further comprisesreceiving, from the file server service, and indication that at leastthe electronic content file was inserted into a file database managementby the file server service.
 19. The method of claim 1, wherein theindication confirming that the electronic content file with registeredwith the trusted data management platform comprises an indication of abinding identifier associated with the binding.
 20. The method of claim1, wherein the trusted ledger comprises a trusted immutable distributedassertion ledger.